1 00:00:00,570 --> 00:00:05,780 In the last video our test that is looking for a 4 0 4 status error instead got a 400. 2 00:00:05,780 --> 00:00:07,640 This is kind of unexpected. 3 00:00:07,730 --> 00:00:13,070 If we go back into our actual request handler of show right now there is absolutely nothing inside of 4 00:00:13,070 --> 00:00:16,640 here that seems to imply that we should be getting a four hundred status code. 5 00:00:17,090 --> 00:00:20,660 So what could possibly going be going on here. 6 00:00:20,660 --> 00:00:23,280 Well maybe we need to do a little bit of debugging. 7 00:00:23,390 --> 00:00:28,840 Remember all of our era handling stuff is being handled through that common module inside a common module 8 00:00:28,850 --> 00:00:29,620 let's open it up. 9 00:00:29,630 --> 00:00:35,760 Let's find that SRT directory and inside there let's find Middleware is inside a middle where's is the 10 00:00:35,820 --> 00:00:37,110 air handler. 11 00:00:37,180 --> 00:00:41,670 So this right here is what is ultimately handling any error that occurs inside of one of our middle 12 00:00:41,670 --> 00:00:46,140 where's so we've got some provision right here for handling customers. 13 00:00:46,170 --> 00:00:51,440 We've also got this case right here in which we will handle any error that is not one of the custom 14 00:00:51,440 --> 00:00:53,160 errors we put together. 15 00:00:53,160 --> 00:00:57,820 It's something generally goes wrong with our application that is not caught by one of his customers. 16 00:00:57,840 --> 00:01:02,670 Then we're going to send back something with a status of 400 and we're going to give a message of simply 17 00:01:02,700 --> 00:01:05,010 something went wrong. 18 00:01:05,010 --> 00:01:08,300 Well the fact that we get back to starts the 400 seems kind of promising there. 19 00:01:08,370 --> 00:01:13,530 Let's try to go back over to our test let's console log the response and see if we get back something 20 00:01:13,530 --> 00:01:15,750 that says something went wrong. 21 00:01:15,750 --> 00:01:21,180 If we do that means that somewhere inside of a request handler or show the one we're just working on 22 00:01:21,390 --> 00:01:25,870 something inside of there is throwing a error that is not a custom error. 23 00:01:25,890 --> 00:01:29,220 So it's an error that you and I didn't really predict would happen. 24 00:01:29,250 --> 00:01:29,520 All right. 25 00:01:29,530 --> 00:01:37,330 So I got to go back over to my show test file I will find a forum for status code test. 26 00:01:37,330 --> 00:01:43,350 I'm going to grab the response we get back from the request and then I will do a console log of response 27 00:01:43,350 --> 00:01:44,080 dot body. 28 00:01:44,100 --> 00:01:47,180 So let's take a look at what actually gets sent back to us. 29 00:01:47,210 --> 00:01:52,860 I'm going to save that go back over and there we go. 30 00:01:52,860 --> 00:01:53,270 OK. 31 00:01:53,310 --> 00:01:55,320 Well still nothing good here. 32 00:01:55,320 --> 00:01:56,870 Why are we not seeing the console log. 33 00:01:56,910 --> 00:01:58,680 All right a little bit of a gotcha here. 34 00:01:58,740 --> 00:02:03,930 Remember whenever we make the request at the very end we are expecting to see a 4 for that is an actual 35 00:02:03,930 --> 00:02:09,630 expectation in the way that expectations work is by throwing an error if that expectation is not satisfied. 36 00:02:09,630 --> 00:02:13,920 So in other words this whole statement right here ends up with an error which causes us to exit the 37 00:02:13,920 --> 00:02:15,720 overall error function. 38 00:02:15,720 --> 00:02:21,490 So to actually get to that console log we have to remove the expectation since we just remove the only 39 00:02:21,490 --> 00:02:24,330 thing that is trying to assert something about the response. 40 00:02:24,370 --> 00:02:29,920 Well now the test is probably going to pass even though our code might not be actually getting a status 41 00:02:29,980 --> 00:02:31,930 of 4 0 4 back. 42 00:02:32,080 --> 00:02:35,260 So the test will pass now but we will at least see the console log. 43 00:02:35,370 --> 00:02:36,370 I'm going to save the file. 44 00:02:36,370 --> 00:02:39,120 Look back over and now we see the console. 45 00:02:39,150 --> 00:02:39,380 OK. 46 00:02:39,420 --> 00:02:43,390 So looks like we get back errors with the message of something went wrong. 47 00:02:43,420 --> 00:02:46,920 So what does that mean well back inside of our error handler. 48 00:02:46,940 --> 00:02:51,860 It means that something is throwing an error inside of our app but is not being caught by this custom 49 00:02:51,890 --> 00:02:52,700 error. 50 00:02:52,730 --> 00:02:58,430 Instead it is going on to this handler this case right here where we send back that just very general 51 00:02:58,430 --> 00:03:05,120 error message so at this point the best way to debug this would probably be to somehow add in a console 52 00:03:05,120 --> 00:03:11,460 log right here and take a look at that error but we can't do that very easily. 53 00:03:11,470 --> 00:03:12,270 Why is that. 54 00:03:12,280 --> 00:03:18,600 Remember we're inside the air handler file the air handler is defined inside of our com module. 55 00:03:18,700 --> 00:03:23,200 If we add in a console log right here or change anything inside of our common module we're going to 56 00:03:23,200 --> 00:03:24,850 have to rebuild this thing. 57 00:03:24,850 --> 00:03:30,340 We're going to have to set a new version on it and redeploy it to NPM and then inside of our ticket 58 00:03:30,340 --> 00:03:35,810 service install that updated version of this common module. 59 00:03:35,860 --> 00:03:39,470 So that's kind of a long process to go through to just do a very quick console log. 60 00:03:39,510 --> 00:03:45,830 So instead we will show you a little trick I can remove the console log right there and then going to 61 00:03:45,830 --> 00:03:52,840 go back over to my tickets directory remember and here's how we install an NPM module. 62 00:03:52,880 --> 00:03:55,240 It gets added into the node modules folder. 63 00:03:55,330 --> 00:04:00,970 So if we open up node modules we'll see all our different start stalled modules so what we can do and 64 00:04:01,000 --> 00:04:07,090 I really do not recommend you do this generally this is kind of like a I have no idea what is going 65 00:04:07,090 --> 00:04:07,400 on. 66 00:04:07,420 --> 00:04:12,580 I have to do some debugging without trying to change some dependency like comment and have to redeploy 67 00:04:12,580 --> 00:04:13,200 and stuff like that. 68 00:04:13,200 --> 00:04:18,970 So again just be really clear does something I really do not recommend you do normally but because we 69 00:04:18,970 --> 00:04:25,650 just want to add in one very small temporary console log we could go into our common module. 70 00:04:25,750 --> 00:04:26,440 Here it is right here. 71 00:04:26,440 --> 00:04:28,400 So mine is under SJ tickets again. 72 00:04:28,450 --> 00:04:30,380 That's my organization name. 73 00:04:30,580 --> 00:04:38,930 We can take a look at the bill directory inside there and find our whereas at air handler J S file. 74 00:04:39,030 --> 00:04:40,440 So this j ust file right here. 75 00:04:40,440 --> 00:04:46,770 This is what is actually truly getting executed when we run our tests so we could potentially make a 76 00:04:46,770 --> 00:04:52,620 temporary very small change to this file just to try to get a console log in our test environment for 77 00:04:52,620 --> 00:04:53,670 right now. 78 00:04:53,670 --> 00:04:58,470 Again I really don't recommend you do this normally because if you start to change stuff in your dependencies 79 00:04:58,470 --> 00:05:03,570 directory Well obviously these dependencies are gonna get blown away all the time as you start to say 80 00:05:03,570 --> 00:05:08,460 rebuild your image or do anything else but just to save ourselves the hassle of rebuilding the common 81 00:05:08,460 --> 00:05:13,970 module and all that stuff we can very temporarily make a very very small change inside of here we've 82 00:05:13,970 --> 00:05:15,750 got the error handler J S file. 83 00:05:15,770 --> 00:05:18,810 So this is the built version of our typescript code. 84 00:05:19,030 --> 00:05:26,310 So inside of here I could add in a console log and take a look at air. 85 00:05:26,410 --> 00:05:31,420 Now I'm going to never close this file until I'm really sure that I have reverted that change after 86 00:05:31,420 --> 00:05:36,970 I've completed my debugging because again we do not want to be making hard changes to our dependencies. 87 00:05:37,230 --> 00:05:41,200 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 88 00:05:41,200 --> 00:05:41,840 now. 89 00:05:41,850 --> 00:05:46,930 Now we can see the actual error that occurred so looks like the actual error that occurred was we were 90 00:05:46,930 --> 00:05:52,690 trying to cast something to an object I.D. for value whatever that is where the I.D.. 91 00:05:53,440 --> 00:05:55,090 Well what's really going on here. 92 00:05:55,360 --> 00:06:03,890 Essentially remember back inside of our actual test we were trying to make a request with this idea 93 00:06:03,890 --> 00:06:04,260 right here. 94 00:06:04,270 --> 00:06:08,720 We're trying to fetch a ticket with that I.D. and then inside of our root handler we were taking that 95 00:06:08,720 --> 00:06:15,740 I.D. and trying to execute a query with it so the air that we are seeing is saying hey that's not a 96 00:06:15,740 --> 00:06:21,650 valid I.D. that is in no way some kind of valid I.D. that Mongo DB is going to understand. 97 00:06:22,130 --> 00:06:26,390 And so we can even see in greater detail right now argument passed and must be a single string of twelve 98 00:06:26,390 --> 00:06:30,160 bytes or a string of twenty four hex characters. 99 00:06:30,260 --> 00:06:33,670 So that's how we could figure out what is going on here. 100 00:06:33,730 --> 00:06:37,760 All right now that we have figured out what is going on we are trying to run our test with some invalid 101 00:06:37,790 --> 00:06:38,420 I.D.. 102 00:06:38,630 --> 00:06:40,470 I'm going to go back to the Eric Handler. 103 00:06:40,490 --> 00:06:45,650 I'm going to remove that console log and save the file again. 104 00:06:45,690 --> 00:06:48,060 So again changes like that to the node modules directory. 105 00:06:48,060 --> 00:06:48,870 Very risky. 106 00:06:48,870 --> 00:06:50,460 I do not normally recommend you do that. 107 00:06:50,460 --> 00:06:54,330 I just want to show you that that is one possible way to solve this issue are to do a little bit of 108 00:06:54,330 --> 00:06:56,270 debugging very quickly. 109 00:06:56,380 --> 00:06:59,030 Now we have kind of a big question to answer here. 110 00:06:59,200 --> 00:07:04,270 The error that we are seeing or the reason that we are getting a 400 is because of essentially that 111 00:07:04,270 --> 00:07:04,840 line right there. 112 00:07:04,840 --> 00:07:07,970 We're trying to take that I.D. That is definitely not a valid I.D.. 113 00:07:08,260 --> 00:07:11,900 So the real question here you know there's kind of there's really two questions. 114 00:07:11,890 --> 00:07:13,900 The first question is how do we fix the test. 115 00:07:13,900 --> 00:07:16,960 Well the obvious thing is we need to put in a valid I.D. here. 116 00:07:16,960 --> 00:07:18,070 That's how we fix the test. 117 00:07:18,070 --> 00:07:18,550 Easy enough. 118 00:07:18,970 --> 00:07:25,120 But the real question is we just got an error inside of our test suite and we had to do some kind of 119 00:07:25,120 --> 00:07:28,290 nasty debugging to figure out what was going on. 120 00:07:28,300 --> 00:07:34,900 So the real question here the underlying question is do we want to add in an additional custom air or 121 00:07:34,900 --> 00:07:38,750 something like that to try to handle stuff like this going wrong. 122 00:07:38,920 --> 00:07:44,650 Do we want to try to put in a try catch statement around it or something like that 123 00:07:48,360 --> 00:07:51,210 or is there some other means of capture capturing this error. 124 00:07:51,510 --> 00:07:54,780 Maybe you want to go back over to the common module and just make sure that if we get some air that 125 00:07:54,780 --> 00:07:59,370 we don't recognize we do some logging information about it so that we can further check our logs in 126 00:07:59,370 --> 00:08:04,040 the future and understand a some unknown error just occurred inside of our app. 127 00:08:04,050 --> 00:08:09,150 Well I'm going to argue and say that the best way to improve our code right now is going to be to make 128 00:08:09,150 --> 00:08:17,180 an update to our air handler middleware back inside of common we've added in some number of custom errors 129 00:08:17,240 --> 00:08:18,680 inside of application. 130 00:08:18,680 --> 00:08:23,000 And right now our kind of belief is that anything that goes wrong is gonna be handled by one of these 131 00:08:23,000 --> 00:08:24,620 custom errors. 132 00:08:24,760 --> 00:08:29,030 Anytime that we get down to this point right here that really truly means that something went wrong 133 00:08:29,060 --> 00:08:32,870 inside of application that we were not really predicting. 134 00:08:32,870 --> 00:08:37,060 And so to be honest with you I personally as a developer I would want to know what is going wrong inside 135 00:08:37,060 --> 00:08:39,910 of my app that I wasn't expecting to happen. 136 00:08:39,950 --> 00:08:46,150 So I think that maybe the best way to deal with this would be to add in a console not air back inside 137 00:08:46,180 --> 00:08:52,350 of our middleware inside of common and log out that air or something like that before making that change. 138 00:08:52,380 --> 00:08:53,730 However this is a long video. 139 00:08:53,760 --> 00:08:57,110 So let's take a quick pause right here and make that change in just a moment.