In the last video our test that is looking for a 4 0 4 status error instead got a 400.
This is kind of unexpected.
If we go back into our actual request handler of show right now there is absolutely nothing inside of
here that seems to imply that we should be getting a four hundred status code.
So what could possibly going be going on here.
Well maybe we need to do a little bit of debugging.
Remember all of our era handling stuff is being handled through that common module inside a common module
let's open it up.
Let's find that SRT directory and inside there let's find Middleware is inside a middle where's is the
air handler.
So this right here is what is ultimately handling any error that occurs inside of one of our middle
where's so we've got some provision right here for handling customers.
We've also got this case right here in which we will handle any error that is not one of the custom
errors we put together.
It's something generally goes wrong with our application that is not caught by one of his customers.
Then we're going to send back something with a status of 400 and we're going to give a message of simply
something went wrong.
Well the fact that we get back to starts the 400 seems kind of promising there.
Let's try to go back over to our test let's console log the response and see if we get back something
that says something went wrong.
If we do that means that somewhere inside of a request handler or show the one we're just working on
something inside of there is throwing a error that is not a custom error.
So it's an error that you and I didn't really predict would happen.
All right.
So I got to go back over to my show test file I will find a forum for status code test.
I'm going to grab the response we get back from the request and then I will do a console log of response
dot body.
So let's take a look at what actually gets sent back to us.
I'm going to save that go back over and there we go.
OK.
Well still nothing good here.
Why are we not seeing the console log.
All right a little bit of a gotcha here.
Remember whenever we make the request at the very end we are expecting to see a 4 for that is an actual
expectation in the way that expectations work is by throwing an error if that expectation is not satisfied.
So in other words this whole statement right here ends up with an error which causes us to exit the
overall error function.
So to actually get to that console log we have to remove the expectation since we just remove the only
thing that is trying to assert something about the response.
Well now the test is probably going to pass even though our code might not be actually getting a status
of 4 0 4 back.
So the test will pass now but we will at least see the console log.
I'm going to save the file.
Look back over and now we see the console.
OK.
So looks like we get back errors with the message of something went wrong.
So what does that mean well back inside of our error handler.
It means that something is throwing an error inside of our app but is not being caught by this custom
error.
Instead it is going on to this handler this case right here where we send back that just very general
error message so at this point the best way to debug this would probably be to somehow add in a console
log right here and take a look at that error but we can't do that very easily.
Why is that.
Remember we're inside the air handler file the air handler is defined inside of our com module.
If we add in a console log right here or change anything inside of our common module we're going to
have to rebuild this thing.
We're going to have to set a new version on it and redeploy it to NPM and then inside of our ticket
service install that updated version of this common module.
So that's kind of a long process to go through to just do a very quick console log.
So instead we will show you a little trick I can remove the console log right there and then going to
go back over to my tickets directory remember and here's how we install an NPM module.
It gets added into the node modules folder.
So if we open up node modules we'll see all our different start stalled modules so what we can do and
I really do not recommend you do this generally this is kind of like a I have no idea what is going
on.
I have to do some debugging without trying to change some dependency like comment and have to redeploy
and stuff like that.
So again just be really clear does something I really do not recommend you do normally but because we
just want to add in one very small temporary console log we could go into our common module.
Here it is right here.
So mine is under SJ tickets again.
That's my organization name.
We can take a look at the bill directory inside there and find our whereas at air handler J S file.
So this j ust file right here.
This is what is actually truly getting executed when we run our tests so we could potentially make a
temporary very small change to this file just to try to get a console log in our test environment for
right now.
Again I really don't recommend you do this normally because if you start to change stuff in your dependencies
directory Well obviously these dependencies are gonna get blown away all the time as you start to say
rebuild your image or do anything else but just to save ourselves the hassle of rebuilding the common
module and all that stuff we can very temporarily make a very very small change inside of here we've
got the error handler J S file.
So this is the built version of our typescript code.
So inside of here I could add in a console log and take a look at air.
Now I'm going to never close this file until I'm really sure that I have reverted that change after
I've completed my debugging because again we do not want to be making hard changes to our dependencies.
So I'm going to say this I can go back to my terminal and let's take a look at what gets console log
now.
Now we can see the actual error that occurred so looks like the actual error that occurred was we were
trying to cast something to an object I.D. for value whatever that is where the I.D..
Well what's really going on here.
Essentially remember back inside of our actual test we were trying to make a request with this idea
right here.
We're trying to fetch a ticket with that I.D. and then inside of our root handler we were taking that
I.D. and trying to execute a query with it so the air that we are seeing is saying hey that's not a
valid I.D. that is in no way some kind of valid I.D. that Mongo DB is going to understand.
And so we can even see in greater detail right now argument passed and must be a single string of twelve
bytes or a string of twenty four hex characters.
So that's how we could figure out what is going on here.
All right now that we have figured out what is going on we are trying to run our test with some invalid
I.D..
I'm going to go back to the Eric Handler.
I'm going to remove that console log and save the file again.
So again changes like that to the node modules directory.
Very risky.
I do not normally recommend you do that.
I just want to show you that that is one possible way to solve this issue are to do a little bit of
debugging very quickly.
Now we have kind of a big question to answer here.
The error that we are seeing or the reason that we are getting a 400 is because of essentially that
line right there.
We're trying to take that I.D. That is definitely not a valid I.D..
So the real question here you know there's kind of there's really two questions.
The first question is how do we fix the test.
Well the obvious thing is we need to put in a valid I.D. here.
That's how we fix the test.
Easy enough.
But the real question is we just got an error inside of our test suite and we had to do some kind of
nasty debugging to figure out what was going on.
So the real question here the underlying question is do we want to add in an additional custom air or
something like that to try to handle stuff like this going wrong.
Do we want to try to put in a try catch statement around it or something like that
or is there some other means of capture capturing this error.
Maybe you want to go back over to the common module and just make sure that if we get some air that
we don't recognize we do some logging information about it so that we can further check our logs in
the future and understand a some unknown error just occurred inside of our app.
Well I'm going to argue and say that the best way to improve our code right now is going to be to make
an update to our air handler middleware back inside of common we've added in some number of custom errors
inside of application.
And right now our kind of belief is that anything that goes wrong is gonna be handled by one of these
custom errors.
Anytime that we get down to this point right here that really truly means that something went wrong
inside of application that we were not really predicting.
And so to be honest with you I personally as a developer I would want to know what is going wrong inside
of my app that I wasn't expecting to happen.
So I think that maybe the best way to deal with this would be to add in a console not air back inside
of our middleware inside of common and log out that air or something like that before making that change.
However this is a long video.
So let's take a quick pause right here and make that change in just a moment.