Mongoose: Saving not working in local database, works in remote database

[DigitalLeaves]

local: [email protected], running on MacOs Mojave 10.14.4
remote: [email protected], running on Linux Debian Jesse 8

Do you want to request a feature or report a bug?
Report a bug.

What is the current behavior?
Save fails in the local database but works in the remote database.

In the remote database, the record gets saved without a problem and added to the database.
In the local database, the _id for the document is not generated, and I get the following error:

{ MongooseError: document must have an _id before saving
  at new MongooseError (/path/to/api/node_modules/mongoose/lib/error/mongooseError.js:13:11)
 at Timeout._onTimeout (/path/to/api/node_modules/mongoose/lib/model.js:257:18)
 at listOnTimeout (timers.js:327:15)
 at processTimers (timers.js:271:5)
 message: 'document must have an _id before saving',
 name: 'MongooseError' }

If the current behavior is a bug, please provide the steps to reproduce.

This is a gist reproducing the error:
https://gist.github.com/DigitalLeaves/06b514f19ef43e74b5979f6e0d099440

What is the expected behavior?
It should save both documents in both databases.

What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.

Remote:
Node.js v11.10.0
[email protected], running on Linux Debian Jesse 8
MongoDB shell version v3.4.20
git version: 447847d93d6e0a21b018d5df45528e815c7c13d8
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
allocator: tcmalloc
modules: none
build environment:
distmod: debian81
distarch: x86_64
target_arch: x86_64

Local:
Node.js v11.10.0
[email protected], running on MacOs Mojave 10.14.4
MongoDB shell version v3.6.3
git version: 9586e557d54ef70f9ca4b43c26892cd55257e1a5
OpenSSL version: OpenSSL 1.0.2o 27 Mar 2018
allocator: system
modules: none
build environment:
distarch: x86_64
target_arch: x86_64

[vkarpov15]

Remove the _id: false in status.certificate in your userSchema, and it will work on both. We had a bug that we fixed in v5.4.16 that caused _id: false in a nested path to disable _id at the top level.

You should not set _id: false in a nested path. It is unnecessary because Mongoose doesn't set _id on nested paths.

[DigitalLeaves]

Thanks. I removed the _id: false. I didn't know that has changed, in the past, not using _id: false meant mongoose will add an _id to nested objects.

[vkarpov15]

@DigitalLeaves hmm I don't remember that ever being the case. If you use a single nested schema, Mongoose will add _id by default:

const nestedSchema = new Schema({ name: String });
// `nested` will have an `_id` property by default
const parentSchema = new Schema({ nested: nestedSchema });

However, if you inline the schema, nested will not have an _id by default:

// `nested` will **not** have an `_id` property by default
const parentSchema = new Schema({ nested: { named: String } });

I'm fairly certain this has been the case since at least 4.2.0 when we introduced single nested subdocs...

[DigitalLeaves]

Oh sorry, I was referring to nested objects, no nested schemas. I'm fairly certain (because it was a problem for me) that it added an _id if not "_id: false" was specified:

For example, this:

var contactSchema = mongoose.Schema({
    "name": { type: String, required: true }, 
    "registry_number": String,
    "tax_id": String,
    "address": String,
    "phone": String,
    "email": String,
    "website": String,
    "banks": [ { "name": String, "iban": String, "swift": String } ],
    "created": Date
})

would generate and _id for every bank object inside "banks" unless defined like this:

    "banks": [ { _id: false, "name": String, "iban": String, "swift": String } ],

[vkarpov15]

@DigitalLeaves that will, because "banks": [ { _id: false, "name": String, "iban": String, "swift": String } ] is equivalent to "banks": [ new Schema({ _id: false, "name": String, "iban": String, "swift": String }) ] because of how Mongoose handles arrays in schemas. You're right that is confusing, see #7558 for more discussion.

[DigitalLeaves]

Thanks for the explanation! 👍🏻 I defintely would propose making a fixed rule for both cases that's the same (i.e: always _id or never _id unless explicitly defined) to make it less confusing :)

[vkarpov15]

You're right, it is confusing. We're working on it :)