TypeError: Invalid schema configuration - Issue Tracker

UPDATE: Solved it, kinda, I guess?

Hello fellow campers,

Currently working on the 2nd certification project for the Quality Assurance course. Can barely get started because I get this error message whenever I type in npm start to run the server:

TypeError: Invalid schema configuration: undefined is not a valid type at path created_on.default. See Mongoose v8.2.2: Schemas for a list of valid schema types.

… so apparently there’s an issue when setting the default value for the “created_on” key, but I don’t see any issues. Found nothing useful in the suggested link, nor in any other forums. I tested different ways of writing it, double-checked everything with ChatGPT, and it couldn’t find any issues either. I’ve already wasted well over an hour with this, so I’m down to the last resor of asking here.

Relevant snippet (from server.js):

let mongoose = require('mongoose');
mongoose.connect(process.env.MONGO_URI, {useNewUrlParser: true, useUnifiedTopology: true});

const issueSchema = new mongoose.Schema({
  "issue_title": {
    type: String,
    required: true
  },
  "issue_text": {
    type: String,
    required: true
  },
  "created_on": {
    type: Date,
    default: Date.now
  },
  "updated_on": {
    type: Date,
    default: Date.now
  },
  "created_by": String,
  "assigned_to": String,
  "open": {
    type: Boolean,
    default: true
  },
  "status_text": String
})

let Issue = mongoose.model("Issue", issueSchema);

If I comment out the entire previous code, the server does start.

The line of code that triggers the error (from node_modules\mongoose\lib\schema.js ) is:

  if (MongooseTypes[name] == null) {
    throw new TypeError(`Invalid schema configuration: \`${name}\` is not ` +
      `a valid type at path \`${path}\`. See ` +
      'http://bit.ly/mongoose-schematypes for a list of valid schema types.');
  }

FAQ

  • the MONGO_URI variable is correctly setup in the .env file to
    MONGO_URI="mongodb+srv://RodrigoHLC:<password>@cluster0.tmjlhtx.mongodb.net/issue-tracker?retryWrites=true&w=majority&appName=Cluster0"

    ( issue-tracker is the database name)
  • It’s the same cluster I used for previous challenges, so the “accepted IPs” (or something like that) setting is correct.

Dependencies object from package.json:

"dependencies": {
		"body-parser": "^1.19.0",
		"chai": "^4.2.0",
		"chai-http": "^4.3.0",
		"cors": "^2.8.5",
		"dotenv": "^8.2.0",
		"express": "^4.17.1",
		"mocha": "^10.3.0",
		"mongodb": "^6.5.0",
		"mongoose": "^5.11.15"
	},

I will be more thank thankful for any help anyone can provide. I was really counting on using this day to work on this project and I’ve been stuck on this for almost two hours and I’ve barely been able to get my foot on the door.

Your browser information:

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

Challenge Information:

Quality Assurance Projects - Issue Tracker

So apparently, the issue stemmed from adding to the dependencies the same version of mongoose as the one used in the Mongoose/MonboDB lessons, mongoose: ^5.11.15" , as that one seems to be very outdated (I had ran npm update and npm update mongoose at some point, but I guess that did nothing).

Figured it out by just starting from scratch and running npm install mongoose --save, which added version ^8.2.2 . This version also warns that useNewUrlParser and useUnifiedTopology are both deprecated, and the server starts correctly if I delete them and simply use
mongoose.connect(process.env.MONGO_URI)
without adding the second argument, {useNew;UrlParser: true, useUnifiedTopology: true}

On that note, I was then able to get the original project that was set to mongoose: ^5.11.15" to start the server by changing the mongoose.connect string to
mongoose.connect(process.env.MONGO_URI), {useUnifiedTopology: true} ( so, no useNewUrlParser )

I’ll leave it to someone more knowledgeable than me to comment what the potential cons of these workarounds might be.

Might have something to do with the timestamps option. Which if you want an automatic created_at, and updated_at would be better to use it anyway.

https://mongoosejs.com/docs/guide.html#timestamps


I wonder if setting the timestamps option to false would change anything and allow you to use those property name with Date.now. Not that I would suggest it, just use the timestamps option instead.

1 Like