MongoDB and Mongoose - Create and Save a Record of a Model

Tell us what’s happening:

My code:

const createAndSavePerson = (done) => {
  let sergiu = new Person({
    name: 'Sergiu',
    age: 33,
    favoriteFoods: ['Lasagna', 'Pizza']
  });, data) => {
      done(null, data);}

Failed test results:

// running tests
Creating and saving a db item should succeed
// tests completed
// console output
[Error: Missing callback argument]

I’ve looked through multiple forum threads, and tried multiple “solutions”.

###Your project link(s)

solution: http://localhost:3000

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36 Edg/

Challenge Information:

MongoDB and Mongoose - Create and Save a Record of a Model

try to find which callback is giving this error

If I’m understanding the lessons and terminology so far, my only callback function is the
(error, data) => {…}
function, which looks fine to me

Your code should be passing.

Do you see any error in the server console about not supporting callbacks?

Did you use/stay with the same version of Mongoose as in the boilerplate?

What do you get when you run npm view mongoose

1 Like

My fork was one commit behind. Updated that and now it works.

I don’t see how the latest commit can have any effect on this project passing locally. It is just a Gitpod config file.

Your last reply gave me the thought of checking versions and updating where I could find.
The first thing I tried was the git repository and that was the only thing I did. Test then worked.

This entire section is giving me difficulties, tho, so maybe there’s something I accidentally did. Currently trying to do the Timestamp project, but my basic

app.get("/api/", (req,res) => {
  console.log("Received request for /api/");
    unix: new Date().getTime()

is giving me a

Cannot GET /api/

I set aside my solution:

app.get("/api/:date?", (req, res) => {
  const dateParam =; 
  const dateObject = new Date(dateParam); 

  if (isNaN(dateObject.getTime())) {
    return res.json({ error : "Invalid Date" }); 

  const unixTimeStamp = dateObject.getTime(); 
  const utcString = dateObject.toUTCString(); 

  res.json({ unix: unixTimeStamp, utc: utcString }); 

…because I can’t test it.

I am missing something fundamental about the back-end dev courses.
Copied the repository, forked it, used “npm i” and “npm start”, and got to coding. The page loads, modifying the HTML in the views/index.html modifies the localhost:3000 page, but I am at a complete loss and have been trying to figure it out for the past 3 hours.

I am sorry for the rant, especially in a closed forum post, and with a separate forum topic I should be opening instead… but I am tired and upset.

I should mention I’m running everything locally

How are you testing the API endpoint?

If you have a /api/ route, that is what you should go to in the browser


For the /api/date? route, it would be .


You do not need the /api/ route because you are using an optional parameter date? so that should work for http://localhost:3000/api as well.

The Date constructor does not work with a number as Type string (which is what the parameter is).

new Date(1451001600000)
Fri Dec 25 2015 01:00:00 GMT+0100 (Central European Standard Time)

new Date('1451001600000')
Invalid Date

If no parameter is supplied, you should respond with the current date, not an invalid date.

I am currently trying to obtain anything other than “Cannot GET /api/testing”


using this code:

app.get("/api/testing", (req, res) => {
  res.json({ test: completed }); 


Currently troubleshooting and going back a few lessons to see where I’m getting confused.

Remember to restart the server anytime you make a change.

I would suggest you add --watch to your start script.

"start": "node --watch index.js"
1 Like

Thank you so much!

I thought I was, manually, by usinc Ctrl+C to close and starting it back up, but that’s obviously given me mixed and inconsistent results.

It is also really easy to forget.

I have advocated for implementing auto restart for the campers to the boilerplate. But that wasn’t agreed to by the dev team.

I did recently add notes for the first Express.js challenge on how to implement auto restart.

1 Like

Any disadvantage from having auto restart?

No, not really. You would usually develop using some sort of auto restart mechanism (and related mechanisms for frontend, like Hot Module Replacement).

You do have to do a sanity check now and then by force quitting and restarting when things do not behave as expected. But that happens with all auto processes.

The reason for not implementing it for the camper is likely more about not doing things behind their back, at least not without teaching it first.

I still think the boilerplate should have a dev script with --watch and it should be mentioned in the challenge text.