Cannot pass 2nd and 3rd test of URL shortener FCC Project

Project Feedback
#1

Tell us what’s happening:
The project cannot pass the 2nd and 3rd test cases. However I already try testing by myself and everything works as intended.
I have also tried to use repl.it as well as glitch and also test on both websites and it works fine but it cannot pass the tests.

Your project link(s)
solution : https://url-shortener-moonlight.glitch.me
Sourcecode: Glitch :･ﾟ✧

Your browser information:
User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36.

Challenge: URL Shortener Microservice

Link to the challenge:

#2

The best way to debug issues like this is to console.log() all your response objects before you send them via return res.json(...) and work back from there. When I did that, I produced a

{
  err: 'Cast to Number failed for value "undefined" at path "short_url" for model "Url"'
}

error which I assume is coming from one of your catch blocks. If that doesn’t help, try logging your route inputs. Adding a

console.log(id);

near the beginning of your /shorturl/:id route logged undefined. If that still doesn’t find the problem, try logging the documents return by your find() calls to your mongoDB.

1 Like
#3

I think the problem is from freeCodeCamp side because if we input the wrong format or sth, it should fall into the catch block right? But if it is a right input, it should work normal, and what I have done worked just like that (You input right format, it gives u the answer. You input wrong, it gives error message). As for error catching, freeCodeCamp test cases only validate the “Invalid Url” error which my project already passed. Anw, Do you know how can I report this problem to freeCodeCamp staff?

1 Like
#4

No, it’s not necessarily on the fCC side (it’s not in this case, as my project is working against the current tests, from repl.it, right now).

If id is undefined here, something is swallowing it somewhere, especially if you are trying to validate it. You really need to log the inputs to the routes as early as possible and then log all the responses from the routes right before sending the response and make sure that everything is as you expect. If logging your route inputs in the router is not helping, back up and add a root level logger to server.js (there is a challenge about this) to log all the route inputs to make sure you are getting the inputs and nothing is happening to them. I did this on my working project and all the inputs are as expected. When I did it on your project, the tests did not send a number on the /api/shorturl/:id GET, but the test should be getting that number from your JSON response. Logging your counter variable in /api/shorturl/new should be helpful.

You may also have a problem with your CORS setup. I’m not sure what the default is using app.use(cors()); as you have, but you need to allow all hosts to see your API if that doesn’t already do so.

2 Likes
#5

Thank you so much my friend. The problem I got was because of the way I debugged :rofl:. My problem was that when I submitted I didn’t check my log. So the solution is to

  1. console.log() the necessary data out (In my case, inside the middleware file)
  2. After I submit to FCC, I have to go back and check those console.log() result.
1 Like
#6

Glad it’s working. During development I will log at several places at the first sign of trouble:

  1. at root level, logging all route input
  2. in the validation, if I have it
  3. at the beginning of a route, with all the inputs
  4. at the route responses, just before returning
  5. at all catch blocks and anywhere else I am handling an error

You can use console.log() for all these, and then once you have the project working and are polishing it, you can add an actual logging package and change all these console.log() statements to log with your logger at the debug level or the error level for ones that are handling errors. That way, the information is always there and when something goes wrong, you can just turn on the logging and see what is happening.

It’s a lot of places to generate output, but I have used this method to fix all manner of mistakes in routes, validation, business logic, and even in stuff like using req.params, req.body and req.query in the wrong routes.

2 Likes
#7

Thank you very much, man!