MongoDB
75 verified issues
DeprecationWarning: `open()` is deprecated in mongoose >= 4.11.0, use `openUri()` instead
DeprecationWarning: `open()` is deprecated in mongoose >= 4.11.0, use `openUri()` instead, or set the `useMongoClient` option if using `connect()` or `createConnection()` Mongoose 4.11.0, MongoDB 2.2.29, NodeJS 8.1.2
Official TypeScript definitions
Official TypeScript definitions
Add 'promise' return value to model save operation
Add promise return support to save operation, currently returns undefined. There are multiple return paths depending on validation and save state that would need to be updated. This would allow chaining of multiple save operations with .then() instead of nesting.
Support for embedded documents / dbrefs
I remember there was a message about adding DBRef support via a plugin or something, is this coming anytime soon? An since it's a somewhat related issue, why there's a way to define an array of embedded documents and (as far as a I can tell) no way of embedding a single document? [code block] And the output: $ node test.js TypeError: undefined is not a function at CALL_NON_FUNCTION_AS_CONSTRUCTOR (native) at Schema.path (/home/bobry/code/mb/support/mongoose/lib/mongoose/schema.js:119:24) at Schema.add (/home/bobry/code/mb/support/mongoose/lib/mongoose/schema.js:88:12) at new Schema (/home/bobry/code/mb/support/mongoose/lib/mongoose/schema.js:26:10) at Object.<anonymous> (/home/bobry/code/mb/test.js:9:15) at Module._compile (node.js:462:23) at Module._loadScriptSync (node.js:469:10) at Module.loadSync (node.js:338:12) at Object.runMain (node.js:522:24) at Array.<anonymous> (node.js:756:12)
Performance drop from 4.13.10 to 5.0.1
Do you want to request a feature or report a bug? Bug What is the current behavior? After upgrading from `4.13.10` to `5.0.1` on production environment, we noticed a real performance drop in all requests using mongoose models : ~200ms per response. We didn't release any code change apart from the `mongoose` dependency upgrade. And we don't use any particular feature of mongoose apart from models & schemas. After applying a fix to revert to `4.13.10`, everything went back to normal. Deploying with `5.0.1` : Reverting back to `4.13.10` : If the current behavior is a bug, please provide the steps to reproduce. More of a performance issue than a bug, so I'm not sure I will be able to reproduce it outside of a production environment. If someone knows any way to benchmark this I will be happy to try 😊 What is the expected behavior? Having response times around ~20ms for 150 RPS. Please mention your node.js, mongoose and MongoDB version.* node.js 8.9.4, mongoose 5.0.1, MongoDB 3.4.10. If it's of any use, we are on a cloud managed (Atlas) sharded cluster.
Updating the path '__v' would create a conflict at '__v'
It happens if I call findOneAndUpdate or findByIdAndUpdate. If I remove __v from document, it does not appear. ../node_modules/mongoose/lib/query.js:3119:9 MongoDB shell version v3.6.1 Mongoose v.4.13.9 Node v.8.9.4
How to share the connection pool across multiple databases
In node-mongodb-native, I can share the connection pool across multiple databases: <code> var mongodb = require("mongodb"), mongoserver = new mongodb.Server(host, port, server_options), db_connector = new mongodb.Db(name, mongoserver, db_options); db_connector.open(callback); </code> And then I use <code>db_connector.db(name)</code>, this returns a new db instance that shares the connections off the previous instance but will send all commands to the database name . This allows for better control of resource usage in a multiple database scenario. HOW CAN I DO THIS IN MONGOOSE?
Allow hiding schema fields when calling toJSON
This is a feature request to allow hiding of a schema field when converting the document into json. I'm not sure if it would be better if this was set from inside the schema declaration or from the toJSON call, e.g. [code block] or something like [code block]
Convert populate to use $lookup
Before: [code block] After: [code block] Can we normalize this functionality for population using `aggregate` and `$lookup` into a rewrite of the `populate` function (so it would still function the same, but it'd use `$lookup` instead?
{ useUnifiedTopology: true } leads to MongoDB connection error: MongoTimeoutError: Server selection timed out after 30000 ms
*Do you want to request a feature or report a bug? A bug. What is the current behavior? After updating to Mongoose 5.7.1, the following warning appeared: [code block] I added `useUnifiedTopology: true` to my mongoose config object as suggested by the message, even though I'm not using MongoDB replica set or sharded cluster. Here is how I configure and connect using mongoose: [code block] and here is where I used this `mongo.options` object: [code block] The warning is gone but the issue is that mongoose is now no longer able to connect: [code block] Here is how I run MongoDB using docker during development: [code block] If the current behavior is a bug, please provide the steps to reproduce. See above What is the expected behavior? Mongoose should remove the deprecation warning and run fine when using `useUnifiedTopology: true` as mongoose suggests. What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.* Node: v10.16.2 Mongoose: 5.7.1 (latest) MongoDB: db version v4.2.0 Related issues: - https://github.com/Automattic/mongoose/issues/8156 - https://github.com/Automattic/mongoose/issues/8169
model.save response too slow
Probably bug with mongoose 5.0.12 and 5.0.13 mongoose model.save after start project first response 1s, with mongoose 5.0.4 it start fine (this problem only with 1st save, get.request returns fast, after 1st save it works fine) first run with 5.0.4v 55.944 ms first run with 5.0.13v 1076.606 ms first run with 5.0.12v 1076.509 ms node 8.7.0 mongoDB 3.6.1
Cast to number failed for value "undefined"
Hi, with the latest version of mongoose, I have a mysterious problem. If I want to save document without specific typed field because it's not required, mongoose return this error in my face : [code block] This is my model schema. It works fine in 3.8.24 : [code block]
Empty array is saved when a property references a schema
[code block] That will create an empty array of b.foos instead of just leaving the property undefined.
Deprecation Warning
I'm getting this warning [code block] after I do [code block] driver is an instance of Driver class [code block] any thoughts about what Im doing wrong?
Ability to specify which ES6 promises library mongoose uses
See discussion on #1699
Timestamps are not being created
I'm trying to add timestamps to my nested objects, but it's not working. Timestamps are being set only on the root documents (Church). Am I doing something wrong? Here's my schemas: [code block] [code block] [code block] Here's the function I'm using to insert nested documents: [code block] MongoDB: 4.4.6 Mongoose: 5.13.2 Node.js: v14.17.0
Unable to install Mongoose on Windows Server 2008 R2 SP1
When tried `npm install` on Windows Server 2008 R2 SP1, it gives the following messages C:\Users\someFolder>npm install mongoose- > kerberos@0.0.3 install C:\Users\SomeFolder\node_modules\mongoose\node_modules\mongodb\node_modules\kerberos > (node-gyp rebuild 2> builderror.log) || (exit 0) npm WARN optional dep failed, continuing kerberos@0.0.3 npm WARN optional dep failed, continuing kerberos@0.0.3 mongoose@3.8.8 node_modules\mongoose ├── regexp-clone@0.0.1 ├── sliced@0.0.5 ├── muri@0.3.1 ├── hooks@0.2.1 ├── mpath@0.1.1 ├── mpromise@0.4.3 ├── ms@0.1.0 ├── mquery@0.5.3 (debug@0.7.4) └── mongodb@1.3.23 > bson@0.2.5 install C:\Users\SomeFolder\node_modules\mongoose\node_modules\mongodb\node_modules\bson > (node-gyp rebuild 2> builderror.log) || (exit 0) When I run the app, I receive the following error C:\Users\Somefolder>node app.js module.js:340 throw err; ^ Error: Cannot find module 'bson' at Function.Module._resolveFilename (module.js:338:15) at Function.Module._load (module.js:280:25) at Module.require (module.js:364:17) at require (module.js:380:17) at Object.<anonymous> (C:\Users\Somefolder\node_mod ules\agenda\node_modules\mongoskin\node_modules\mongodb\lib\mongodb\collection.j s:10:16) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Module.require (module.js:364:17)
Don't reconnect after disconnection
After upgrading from 4.4.11 to >=4.6.1 we get random disconnections and mongoose never reconnects. mongoose version: 4.6.5 mongodb version: 3.2.9 This is the way I create the connections: [code block] This is the sequence of events I get: [code block] Then none of the disconnected databases reconnect. Due to the random nature of the problem, I won't be able to provide a code to reproduce it. I suspect about something saturated at node.js level or so. Independently of the cause of the disconnection, is there anything I can do to try to reconnect myself?
performance issue of 4.0.0&4.0.1
After upgrading from 3.9.\* to 4.0.0&4.0.1, my node process's CPU usage increased by more than 200%. Each http request which uses mongoose costs cpu % 3 times than before. And when I downgrade back to 3.8.25, everything is OK.
Mongoose not reconnecting when MongoDB driver does
Do you want to request a feature or report a bug? bug What is the current behavior? When connected to a Mongos container that is restarted Mongoose never reconnects. I make sure to pass these options: [code block] However the logs show me that the driver does reconnect: [code block] If the current behavior is a bug, please provide the steps to reproduce. 1 Run a nodeJS app that connects to a Mongos on a Docker container 2 Restart your container What is the expected behavior? Mongoose should be reconnecting when the container comes back online. Please mention your node.js, mongoose and MongoDB version.* nodeJS: 8.9.4 and 9.2.0 mongoose: 5.0.5 mongodb: 3.4.10 EDIT: So I'm using useDb() to connect to other tenant's databases and I just noticed that after the Mongos restart all the calls made to the parent connection db on which I used useDb() works but the calls made on the children connections don't resolve. Also the readyState is never set to 1 on the parent connection even if the connection is properly reconnected.
The CVE-2025-23061 advisory is incomplete and `npm audit` is wrong
Prerequisites - [x] I have written a descriptive issue title - [x] I have searched existing issues to ensure the bug has not already been reported Mongoose version 7.8.4 Node.js version 18 MongoDB server version 6 Typescript version (if applicable) 5.4 Description The commit lists as fixed versions: 8.9.5, 7.8.4, and 6.13.6 The CVE advisory however: Affected versions: < 8.9.5 / Patched versions: 8.9.5 Steps to Reproduce On a project with versions 7.8.4, or 6.13.6 do an: npm audit Expected Behavior No vulnerability reported.
Callbacks Stop Happening
I've been using `mongoose` for a few years, but lately I'm having a lot of trouble where the connection seems to disappear. Connection Settings [code block] The Problem Mongoose just stops calling back. It doesn't emit any errors, memory/cpu is fine on my server & db, and I can connect from any other server. Restarting always fixes it: [code block] Versions On `mongoose 4.4.11`, `mongoose.connection.readyState === UNAUTHORIZED` when callbacks stop. So I upgraded to `mongoose 4.6.0` but within 4 hours the callbacks stopped again, now with `mongoose.connection.readyState === CONNECTED`. Any Ideas Any ideas how I can get this to stop happening? I'm happy to gather any more debugging info, just let me know what info to get.
Is it possible to populate without `_id` ?
I checked the API http://mongoosejs.com/docs/populate.html and tried out. It seems that `populate` can only works on foreign `_id`. Even there is a `match` option, it just add more filtering condition on `_id` query condition. There is no way to just populate with fields not involved with `_id`. In my project, we keep the `_id` as ObjectId and has another field as auto-increment Number. For example, `customers` model has `_id` as Object and `cuid` as incremental number. Other collections just reference to `cuid` not to `_id`. Is would be great to be able to customize this? Is there any design limitation causing this feature missing?
Feature Request: Allow Unique in Array Schema Definition
The following page states currently supported Schema types: http://mongoosejs.com/docs/schematypes.html One feature that would be nice is for Mongoose to enforce uniqueness in Arrays, which could guarantee unique values in an array in Mongoose, like the $addToSet functionality in the Mongo database query language. Current Issue I can only define an array to hold a list of values, which allows multiple instances of the same value. The following code example demonstrates the issue. var schema = mongoose.Schema({ friends : [{type : mongoose.Schema.Types.ObjectId, ref : 'User' }] }) model = new mongoose.model('User') model['friends'].push(ObjectId('12345')) model['friends'].push(ObjectId('12345')) model.save() Mongo document now looks like: {friends:[ObjectId('12345'),ObjectId('12345')]} Suggested Fix Enhance the schema model to allow unique attribute for an array, which internally uses the Set() object in Mongoose. Then once save() is called, mongoose will convert the set to an array and use the "$addToSet" mongodb operator that will ensure values are unique in the array. Something like the following code snippet would be desired: var schema = mongoose.Schema({ friends : [{type : mongoose.Schema.Types.ObjectId, ref : 'User', unique: true }] }) model = new mongoose.model('User') model['friends'].push(ObjectId('12345')) model['friends'].push(ObjectId('12345')) model.save() Mongo document now looks like: {friends:[ObjectId('12345')]} Current Method Currently it is
Upgrading 5.10.4 to 5.10.5 cause test run to hang
*Do you want to request a feature or report a bug? Might be a bug What is the current behavior? Update: I think I managed to drill down a little but still not quite sure. I isolated to a few more specific test case suite. Will update here once I have more findings. Update: Sorry, wasn't able to find anything conclusive yet.. --- When using `5.10.4`, when I ran my test (ts-mocha), it run smoothly as usual without any issue but once I upgrade to `5.10.5`, there seem to have some weird issue like "hanging" on the test case. I don't have any error, or anything. Based on the changelog, the only thing it seem to possibly affect is the upgrade of `mongodb driver` to 3.6.2 but I am not sure where to begin checking. I'm not sure if it has anything to do with #9203 ? Just a wild guess. I am still able to run my application without issue, it seem to be affecting the test run now All test case seem to hit the `timeout` limit of 10s I understand this is little to go with, but do let me know what I can do to provide more information What is the expected behavior? Test to run as per usual to what it does in 5.10.4 or before What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version. Working node: v12.18.4 mongoose: 5.10.4 mongodb: 4.2.0 Not working* node: v12.18.4 mongoose: 5.10.5 mongodb: 4.2.0
docs embedded in object w/ arbitrary keys?
Is there a way to use embedded docs within a object that doesn't have predetermined keys? i.e. Rather than having a situation like this: [code block] Being able to say something like: [code block] Makes it a little more array like in that way - but the idea is that I don't know the keys in advance, but I'd still like to be able to have an embedded doc.
Handle cast error on find when objectId is invalid
Do you want to request a feature or report a bug? Bug What is the current behavior? I'm trying to find an item by its _id, but when I try to handle the possible "error", when the client sends an id that doesn't exist and then return it as an user friendly error, it's getting into the "catch" function and resulting in an Error 500 to the user with a very big error message. I tried to find a method to handle it on google and even here, but I didn't find anything. If the current behavior is a bug, please provide the steps to reproduce. [code block] What is the expected behavior? I want to handle this kind of "error" that for me isn't an error. It's just an invalid item to search. Please mention your node.js, mongoose and MongoDB version.* Node: v7.4.0 Mongoose: 4.10.5 MongoDB: v3.4.4
Use MongoClient.connect() instead of authenticate() if user provides URI to avoid Db.prototype.authenticate deprecated
I'm using a connection method like : [code block] ... as indicated in the docs, but receiving the following warning on NodeJS console : [code block] (I get an authentication failure if I omit `?authSource=admin`) Is this normal at this stage (do we need to wait for a next mongoose release ?), or what should I change from now ? Versions : Node : 7.10.0 Mongoose : 4.10.3 MongoDB : 3.4 Thank you.
Mongoose 4.6.2 produces error "MongoError: no primary found in replicaset" while 4.4.19 works just fine
Simple connection to a MongoDB replica set. Works great in Mongoose 4.4.19 but not in 4.6.2 mongoURI = "mongodb://IP:27017,IP:27017/" + dbName + "?replicaSet=my_replica_set"; Using 4.6.2, I have tried the following: - defining replset in connection options - connectWithNoPrimary: true - tried both mongoose.createConnection vs mongoose.connect - included and excluded arbiter node in the connection string If connection string only uses one database, it works fine. I am really curious as to why this error occurs. Any thoughts? Full Error: /Users/adeel/dev/navi/euler/node_modules/mongodb/lib/replset.js:360 process.nextTick(function() { throw err; }) ^ MongoError: no primary found in replicaset at /Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/topologies/replset.js:631:32 at .<anonymous> (/Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/topologies/replset.js:421:24) at g (events.js:286:16) at emitOne (events.js:96:13) at emit (events.js:188:7) at .<anonymous> (/Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/topologies/server.js:313:21) at emitOne (events.js:96:13) at emit (events.js:188:7) at .<anonymous> (/Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/connection/pool.js:260:12) at g (events.js:286:16) at emitTwo (events.js:106:13) at emit (events.js:191:7) at Socket.<anonymous> (/Users/adeel/dev/navi/euler/node_modules/mongodb-core/li
Throw clean error if save() called in parallel on same doc instance
I have seen a few issues closed already regarding the `#save()` method and swallowing of exceptions. I've got this happening at the moment with the latest version in npm (4.4.12). Here's some code: [code block] I can post a more detailed example if required. Edit: Also, this happens with the promise interface as well, so `giftcard.save().then()` has the same result.
Docs page for how to fix deprecation warnings
After #6917 it should now be possible to clear up all deprecation warnings by: Replacing `update()` with `updateOne()`, `updateMany()`, or `replaceOne()` Replacing `remove()` with `deleteOne()` or `deleteMany()` Setting `mongoose.set('useFindAndModify', false);` Setting `mongoose.set('useCreateIndex', true);` * Setting `mongoose.set('useNewUrlParser', true);` Need a docs page to summarize this.
Mongoose slows down performance of VSCode (TSServer) by a lot
Do you want to request a feature or report a bug? bug What is the current behavior? It slows down vscode by a lot, even with small projects. I have a very small project, with like 2 small schemas, and the 2 other files, containing on average 160 lines of code, and vscode slows down a lot as soon as I install mongoose. This does not happen when I install most other libraries (haven't tested them all lmao). If I uninstall mongoose, it comes back and works perfectly normal. To clarify "slowing down" means that typescript language server needs 3-5 seconds to realise that I'm importing somethign invalid, and just vscode in general to realise I'm importing something that's never used takes around 2-4 seconds. Usually it happens in under a second so like.. you know... And it's not like vscode is taking a lot of ram/cpu either, it just grows slow. Btw I think this is a mongoose issue, since it happens with no other library, its a special case here Reloading typescript server or project doesn't help If the current behavior is a bug, please provide the steps to reproduce. Have vscode to edit your code Install mongoose on your current project (`npm i mongoose` My tsconfig.json: [code block] What is the expected behavior? It to not be like this, lmao. What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.* Node: v16.2.0 Mongoose: 5.12.13 Linux: 5.12.7-arch1-1
findById returns no results even with correct ObjectId
Configuration: Mongoose 4.0.5, MongoDb 3.0.4, Node 0.12.4 Issue does not appear on Mongoose 3.8.30 My database has the following data: [code block] I query it with Mongoose using the following syntax: [code block] which returns null for both error and user. Strangely enough Mongoose's debugging shows the following, correct query: [code block] which queried directly on MongoDB finds the expected data: [code block] I tried various alternatives such as directly initializing an ObjectId object or taking an ObjectId from a `find()` result which leads to no results either. As stated above reverting back to Mongoose 3.8 resolves the issue.
No retries are made after "failed to connect on first connect"
By default, mongoose throws an Error if the first connect fails, which crashes node. So to reproduce this bug, you will need the following code in your app, to catch the error and prevent the crash: db.on('error', console.error.bind(console, 'connection error:')); Now we can reproduce this bug as follows: 1. Shut down your MongoDB 2. Start up your node app that uses mongoose 3. Your app will log: `[MongoError: failed to connect to server [localhost:27017] on first connect [MongoError: connect ECONNREFUSED 127.0.0.1:27017]]` 4. Start up your MongoDB again 5. Observe that mongoose does not now connect to the working MongoDB. The only way to get reconnected is to restart your app, or to use a manual workaround. Expected behaviour: Since `autoreconnect` defaults to true, I would expect mongoose to establish a connection soon after the MongoDB is accessible again. Note: If the first connect succeeds, but the connection to MongoDB is lost during runtime, then autoreconnect works fine, as expected. The problem is the inconsistency if MongoDB is not available when the app starts up. (If this is the desired behaviour, and developers are recommended to handle this situation by not catching the error, and letting node crash, then I can accept that, but it is worth making it clear.) node v4.4.1, mongoose@4.9.4, mongodb@2.2.19, mongodb-core@2.1.4
Model Update method does not respect validators
I can use the model.Update method to update to any value regardless of schema constraints For example if I have a Schema with a enum property, using update I can change to any value outside of the enum constraint, thus invalidating the set. The expected behavior was to throw an error if the updated value did not validate. I suggest an extra option to the update method to exit on the first error or not.
Support for Asynchronous Virtual
I'd like to express some virtual properties that perform asynchronous work, such as inspecting other Mongoose models. It would be nice if the virtual getters and setters accepted an optional done function that would be invoked after the async work completed.
MongoDB $ne key collision in object literal silently uses wrong operator
In a MongoDB query, writing `{ status: { $ne: null, $ne: '' } }` creates a JavaScript object with a duplicate key. The second `$ne` silently overwrites the first. The query only filters out empty strings, never null values. TypeScript does not warn about duplicate keys in object literals by default. The correct approach is `$nin: [null, '']`.
DeprecationWarning: collection.ensureIndex is deprecated. Use createIndexes instead.
After update to version `5.2.9` I'm getting this message in console all the time, when I start my web app: `DeprecationWarning: collection.ensureIndex is deprecated. Use createIndexes instead.` And I don't use neither of them.
MongoDB analytics active user count always 0 when country filter applied
An analytics dashboard shows correct total active user counts but returns 0 when filtering by country. The query uses `{ _id: { $in: userIds }, _id: { $in: countryUserIds } }` — a JavaScript object with two identical `_id` keys. The second key overwrites the first, so only the country filter is applied, but the country user list includes all user types (drivers, admins), not just the user type being counted.
pre, post middleware are not executed on findByIdAndUpdate
Because a findAndUpdate method is presented to cut down the following code: [code block] to this: [code block] We need to use pre, post middleware exactly the same. At now pre, post middleware are not executed when I make findByIdAndUpdate.
Problem with connection to db , queries hang. Reverting to mongoose 4.6.6 solves it
Mongoose 4.7.7 Do you want to request a feature or report a bug? I want to report a bug What is the current behavior? All request towards the db just hang and do not return anything If the current behavior is a bug, please provide the steps to reproduce. [code block] All queries hang and return nothing `Program.find()` will just hang Fixed if I downgrade to mongoose@4.6.6 The change in 4.7.7 is a dependency version update muri@1.1.1 to muri@1.2.0. I am guessing that is was is causing the issue Please mention your node.js, mongoose and MongoDB version.* mongoose 4.7.7 node 6.9.2 MongoDB 3.2.3
Way to handle mongoose.connect() error in promise catch handler
How to handle `mongoose.connect()` error in catch handler? I want to use application initialization chain but can't do that because `mongoose.connect()` does not return rejected promise. It returns rejected promise only if I specify callback, but it's not a perfect solution. Example: [code block] Workaround: [code block] I think `mongoose.connect()` throws async error instead of return rejected promise in order to not break backward compatibility. Users expect that application will be finished with error code if something went wrong with mongoose connection establishment. If `mongoose.connect()` returns rejected promise application will be finished with 0 code and nothing will be output to console. So it will be good to have some way to say `mongoose.connect()` to return promise. Maybe something like `exec()`: [code block]
Discriminator support for Sub-Documents
Starting a feature request to allow discriminator use within sub-documents. Playing around with a possible API: [code block]
Error: cyclic dependency detected
Running the latest version of Node.js on macOS. Also running the latest version of Mongoose. Seeing `Error: cyclic dependency detected` with literally no way to debug. Everything points back to Mongoose. Any suggestions? Started happening today. [code block]
11000 E11000 duplicate key error index: dbName.users.$_id_ dup key: { : ObjectId('5469eb08370fea375383e2d3')}
I am trying to save an an array of objects into a db using `db.collection.insert` but I am getting this error: [code block] I've tried dropping the database and reinserting but of no use. Also, no document with such id is present in the collection earlier.
Model.find() is not returning all documents
With a particular model, I have ~120 documents. When I run model.find({}, function(err, list) {…}); some documents for that model are not returned. If I add a clause to the query, I can make it return certain matching documents that are not returned with an empty query. The problem can also occur when I specify a query parameter that matches many documents (one or two are missing from the returned results). I'm curious if others have experienced this problem and how they fixed it. Is it a mongoose issue, the mongo native module, or mongodb itself? What did others do to fix it? I am running mongoose 1.3.7 and mongodb 1.8.1 on Ubuntu Linux.
4.7.1 => 4.7.2 : MongoError connection timed out
When testing mongoose@4.7.2 / mongodb@2.2.12, I get: > MongoError: connection 2 to XXXXXX timed out > at Function.MongoError.create (/node_modules/mongodb-core/lib/error.js:29:11) > at Socket.<anonymous> (/node_modules/mongodb-core/lib/connection/connection.js:186:20) > at Socket.g (events.js:286:16) > at emitNone (events.js:86:13) > at Socket.emit (events.js:185:7) > at Socket._onTimeout (net.js:333:8) > at tryOnTimeout (timers.js:224:11) > at Timer.listOnTimeout (timers.js:198:5)' } 'connection 2 to XXXXXX timed out this does not happen with mongoose@4.7.1 / mongodb@2.2.11. More details: - query: aggregate with allowDiskUse(true).read('secondaryPreferred').cursor() - timing: the error happens about 35s after sending the query (before first results are received) - node version: v6.3.0 - npm version: 3.10.9 - connect options: [code block] - query: [code block]
Connection timeout 10000ms when upgraded mongoose from 7.4.5 to 8.7.1
Prerequisites - [x] I have written a descriptive issue title Mongoose version 8.7.1 Node.js version 20.x MongoDB version 6.9 Operating system None Operating system version (i.e. 20.04, 11.3, 10) _No response_ Issue Last night, I upgraded my mongodb and mongoose from versions 5.8.1 to 6.9 and. 7.4.5 to 8.7.1 respectively. I tested on my local. Everything worked fine. I promoted the changes to test env - AWS amplify - things were fine. Then, I moved the changes to production. My db is hosted on mongo atlas serverless cluster. On production, sometimes same queries will work fine but other times give timeout error with 10000ms. I mean same queries behaving differently. I have been scratching my head because both test and prod env are exactly similar except that prod is connected to my domain name. Please assist if someone has knowledge about this. sharing my connection code and one query that fails/passes abruptly. [code block] [code block]
OverwriteModelError with mocha 'watch'
I just updated from 3.4.0 to 3.5.1, and when 'watching' Mocha tests on a model, every time the file reloads, I get a OverwriteModelError from re-'require'ing - and I guess, redefining - the model. There must be some value in making an 'overwrite' an error, but I'm going back to 3.4.0 for now because this is too much of a pain.
Support multiple validator errors
Support multiple validator errors