Automattic / mongoose

MongoDB object modeling designed to work in an asynchronous environment.
https://mongoosejs.com
MIT License
26.81k stars 3.82k forks source link

{ useUnifiedTopology: true } leads to MongoDB connection error: MongoTimeoutError: Server selection timed out after 30000 ms #8180

Closed tschaffter closed 4 years ago

tschaffter commented 4 years ago

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:

(node:41563) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
    at parseFn (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/connect.js:312:5)
    at parseConnectionString (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/core/uri_parser.js:628:3)
    at connect (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/connect.js:266:3)
    at ConnectOperation.execute (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/connect.js:191:5)
    at executeOperation (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/operations/execute_operation.js:83:26)
    at MongoClient.connect (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/node_modules/mongodb/lib/mongo_client.js:216:10)
    at Promise (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/lib/connection.js:632:12)
    at Promise._execute (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/bluebird/js/release/debuggability.js:313:9)
    at Promise._resolveFromExecutor (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/bluebird/js/release/promise.js:488:18)
    at new Promise (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/bluebird/js/release/promise.js:79:10)
    at NativeConnection.Connection.openUri (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/lib/connection.js:629:19)
    at Mongoose.connect (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/mongoose/lib/index.js:327:15)
    at Object.connect (/Users/tschaffter/dev/PHCCollaborationPortal/server/app.js:17:44)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Module._compile (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/pirates/lib/index.js:99:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Object.newLoader [as .js] (/Users/tschaffter/dev/PHCCollaborationPortal/node_modules/pirates/lib/index.js:104:7)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/Users/tschaffter/dev/PHCCollaborationPortal/server/index.js:12:28)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)

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:

        options: {
            // https://mongoosejs.com/docs/deprecations.html
            useNewUrlParser: true,
            useFindAndModify: false,
            useCreateIndex: true,
            useUnifiedTopology: true,
            reconnectTries: 30,
            reconnectInterval: 500, // in ms
        }
    },

and here is where I used this mongo.options object:

// Connect to MongoDB
const mongooseConnectionPromise = mongoose.connect(config.mongo.uri, config.mongo.options);
mongoose.connection.on('error', err => {
    console.error(`MongoDB connection error: ${err}`);
    process.exit(-1); // eslint-disable-line no-process-exit
});

The warning is gone but the issue is that mongoose is now no longer able to connect:

MongoDB connection error: MongoTimeoutError: Server selection timed out after 30000 ms
[nodemon] app crashed - waiting for file changes before starting...

Here is how I run MongoDB using docker during development:

docker run -p ${MONGO_PORT}:${MONGO_PORT} --name mongo -d mongo

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:

vkarpov15 commented 4 years ago

What docker image do you use? Also, do you have a stack trace for the 'Server selection timed out' message?

Novaras commented 4 years ago

Hey, just poking in here to report that I had the same issue.

I myself am not using Docker or any vm. Also to note is that this doesn't seem to happen all the time, however today I was unable to retreive any of my data due to timeouts (30k), and the issue was immediately resolved when removing the useUnifiedTopology flag.

I'm connecting to an Atlas cluster.

Mongoose is 5.7.1 MongoDb is 3.3.2 Node is 12.9.1

Connecting like this:

mongoose.createConnection(uri,
    {
        useCreateIndex: true,
        useNewUrlParser: true,
        useUnifiedTopology: true, // commented out currently
        dbName: db_name
    });

The model is created like this:

import mongoose from 'mongoose';
import * as db_conns from '../db-connections'; // this is an object of connections generated via createConnection

// ... schema definition, for a model called 'article' from a collection called 'article'

// `site_content` is the name of a connection
export default db_conns.connections.site_content.model(`article`, schema, `article`);

Then it's fetched like this:

// ...
await query.model.find(query_expr).limit(30); // query_expr can change, however even an empty expression ({}) will cause the same issue
// ...

The find call hangs and issues the timeout error.

tschaffter commented 4 years ago

@vkarpov15 I'm using the latest mongo image that provide MongoDB v4.2.0. https://hub.docker.com/_/mongo

indrajit-rathod commented 4 years ago

I am also getting the same error after adding the { useUnifiedTopology: true } , although the error is randomly occuring. There is something definitely wrong. I am using the latest mongo image.

pabloabreu1986 commented 4 years ago

mongoose .connect(process.env.MONGO_URI, { useUnifiedTopology: true, useNewUrlParser: true, }) .then(() => console.log('DB Connected!')) .catch(err => { console.log(Error, err.message); }); When it starts I get at the console: [Function: Error] { stackTraceLimit: 16, prepareStackTrace: undefined } connection 0 to acccluster-shard-00-01-xx47j.mongodb.net:27017 closed

shanmugarajbe commented 4 years ago

Any solutions? Even I am facing this issue now...

samimhm commented 4 years ago

I have the same issue. I'm a junior programmer and it's my first time using nodejs-express-graphql-mongoose-mongodbAtlas.

(node:9392) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms at Timeout.setTimeout (MyAppPath\graphql2\node_modules\mongodb\lib\core\sdam\topology.js:850:16) at ontimeout (timers.js:436:11) at tryOnTimeout (timers.js:300:5) at listOnTimeout (timers.js:263:5) at Timer.processTimers (timers.js:223:10) (node:9392) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:9392) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. events.js:174 throw er; // Unhandled 'error' event ^

Error: read ECONNRESET at TLSWrap.onStreamRead (internal/stream_base_commons.js:111:27) Emitted 'error' event at: at TLSSocket. (MyAppPath\node_modules\mongodb\lib\core\connection\connection.js:321:10) at Object.onceWrapper (events.js:286:20) at TLSSocket.emit (events.js:198:13) at emitErrorNT (internal/streams/destroy.js:91:8) at emitErrorAndCloseNT (internal/streams/destroy.js:59:3) at process._tickCallback (internal/process/next_tick.js:63:19)

clarkmcc commented 4 years ago

We're also getting the same error on our production server after enabling useUnifiedTopology.

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout [as _onTimeout] (/opt/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)
indrajit-rathod commented 4 years ago

I started to encounter another problem now MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 topologyDescriptionChanged listeners added.

When I searched for this warning I came across this mongoDB document https://jira.mongodb.org/browse/NODE-2123

It states both the errors "Server selection timed out " as well as "MaxListenersExceededWarning" and both the errors are due to the unified topology change. I guess this was a breaking change which was never mentioned.

Since I am encountering this error on my live server I have no choice but to set { useUnifiedTopology: false }. I hope someone from the community can focus on this issue and resolve it or provide some suggestions to resolve it.

SimeonStoykov commented 4 years ago

I am also getting both errors (Server selection timed out after 30000 ms and MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11) when using useUnifiedTopology so this is happening to everyone that uses this option I guess.

vkarpov15 commented 4 years ago

I've tried to repro this, but I haven't been able to repro. I tried a few options:

1) Killing the server right before querying

2) Querying with a disconnected connection

3) Successfully executing a query

I have yet to see this error message in any case. Can you please modify the below script to demonstrate this issue?

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017/test');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));

  console.log('Query...');
  await Model.findOne();
  console.log('Done');
}

Or at least provide some information about what version of Mongoose you're using; whether you're using a standalone server, replica set, or sharded cluster; and whether you're using Mongoose directly or via another npm module?

Novaras commented 4 years ago

I'm fairly convinced this is not an issue with mongoose, but with Mongo itself.

@vkarpov15, please see my comment, I outlined my environment there. I'm using mongoose directly.

indrajit-rathod commented 4 years ago

@vkarpov15 for me this issue appears randomly every 2-3 days when the server is running so even if I provide you the code you will have to monitor the server continuously.

indrajit-rathod commented 4 years ago

Has anyone got around this issue?

Novaras commented 4 years ago

Has anyone got around this issue?

You can just not use this flag for the time being. Mongo will warn you that it will be disabled in future or something but for the time being it seems to totally solve this issue.

basma-abdin commented 4 years ago

Has anyone got around this issue?

You can just not use this flag for the time being. Mongo will warn you that it will be disabled in future or something but for the time being it seems to totally solve this issue.

when i don't use the flag useUnifiedTopology: true , i have this error and the app stopped, mongoose veriosn: 5.7.4 Screenshot from 2019-10-10 11-07-11

rpedroni commented 4 years ago

Can confirm that commenting useUnifiedTopology out solves the problem in my build. Also happening in a (apparently) random fashion.

bke-daniel commented 4 years ago

@rpedroni Sadly, it doesn't for us...

leovazquezz1 commented 4 years ago

Also happening here. Our production server responds with the bellow message. I gues I will comment useUnifiedTopology for now

MongoDB Connection Options

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Server Log

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 
rvanmil commented 4 years ago

We are having this issue as well and we do not use mongoose. It appears to be a problem with the MongoDB driver for Node.js itself. The issue has also been reported over here https://jira.mongodb.org/browse/NODE-2249 Version 3.3.3 of the driver which was published today should add more details to the MongoTimeoutError. It is also recommended to update the driver due to a bugfix.

This error is the result of the driver being unable to connect to a server satisfying the read preference of a given operation (or initial connect). This could be for a number of reasons, including your connection string being invalid or nodes in your cluster being down. If you update to the latest v3.3.3 of the driver we include a new reason field with the MongoTimeoutError which will help us further investigate your issue. Additionally, this version includes a bug fix which would result in a timeout error on initial connect if any member of a replicaset was not available. Please update your driver, and let us know if you continue to experience this issue.

Quoted from https://jira.mongodb.org/browse/NODE-2249?focusedCommentId=2485028&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-2485028

zicodeng commented 4 years ago

Same here, happens in both development and production, connecting to Mongo Atlas :(

mrwillis commented 4 years ago

Also have this issue connecting to mongodb atlas. Typically happens after atlas does a server restart or update or something of the like.

vkarpov15 commented 4 years ago

So I'm still unable to repro this locally with a replica set. The below script continues to execute queries successfully even with replica set failover or killing the primary. Don't get any server selection timeout errors:

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017,localhost:27018,localhost:27019/test?replicaSet=rs');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));

  while (true) {
    console.log(new Date(), 'Query...');
    await Model.findOne();
    await new Promise(resolve => setTimeout(resolve, 5000));
  }
} 

My best guess is @rvanmil 's explanation is correct. Try upgrading to mongoose@5.7.6 (which I'll ship in a couple hours) and see if this issue persists.

vkarpov15 commented 4 years ago

Also, does anybody know if there's a way to trigger a restart in Atlas? Maybe this issue only occurs if you're using Atlas?

rvanmil commented 4 years ago

@vkarpov15 I think you have to pause/resume the cluster to trigger a restart. It's only possible on M10+ sizes. I also wonder if this might be an Atlas issue instead. I haven't been able to test the updated MongoDB driver yet, but I'll report back over here once I do.

MattGibbard commented 4 years ago

I'm also having the same issue today with Atlas free tier regardless of the useUnifiedTopology flag. Error: MongoTimeoutError: Server selection timed out after 30000 ms

I can get a connection using another MongoDB service such as mLab.

gilbertoalmeida commented 4 years ago

I was having the same issue and it ended up being something a bit stupid, but I will share it anyways because it may help someone that ends up here too.

I checked the 'reason' field in the MongoTimeoutError and it said 'MongoError: bad auth Authentication failed.' That's when I realized I was using the mongoDB password in my connection string and not the user password. Now it works fine.

bockbone commented 4 years ago

If you're using MongoDB Atlas, you should whitelist your ip address.

Go to Network Access, edit the current ip address and click on Allow Access from Anywhere.

mazid1 commented 4 years ago

I am only facing this issue while using Atlas. I have tried adding 0.0.0.0/0 IP in whitelist but it also did not work.

I am using:

Could not reproduce in local mongodb server. There, every query just works successfully.

mrwillis commented 4 years ago

This has nothing to do with access. I have 0/0/0/0 access and this occurs every time server restarts on atlas. You can repro by making a multi node cluster (m10+) and setting the scheduled maintenance time. Then run a long running service and it should produce the error when it restarts.

On Wed., Oct. 23, 2019, 7:42 a.m. Mohammad Mazedul Islam, < notifications@github.com> wrote:

I am only facing this issue while using Atlas. I have tried adding 0.0.0.0/0 IP in whitelist but it also did not work.

I am using:

  • mongoose: 5.7.6
  • node: v10.16.3
  • Atlas free tier

Could not reproduce in local mongodb server. There, every query just works successfully.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Automattic/mongoose/issues/8180?email_source=notifications&email_token=AAUHUCYYQIQ5U42IBYT7CQTQQA2B7A5CNFSM4IYQ3ZB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECBDC4I#issuecomment-545403249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUHUCY5SNFGGCPTGW6GH5DQQA2B7ANCNFSM4IYQ3ZBQ .

tanjilrahman commented 4 years ago

I also used to have that issue. But now after putting both 0.0.0.0/0 and my IP address to whitelist from atlas solves the problem.

crobinson42 commented 4 years ago

https://jira.mongodb.org/browse/NODE-2147

crobinson42 commented 4 years ago

~This is only an issue with MongoDB Atlas.~

phpedinei commented 4 years ago

I have a some problem using MongoDB Atlas.

EpicHigh commented 4 years ago

I have the same problem using normal MongoDB.

anzairyo0127 commented 4 years ago

I have successfully reproduced the condition that causes "MongoTimeoutError: Server selection timed out after 30000" using docker-compose. https://github.com/anzairyo0127/mongodb-connection-bug

First start this application

$ docker-compose up -d
$ docker-compose exec a mongo /tmp/conf/init.js
$ docker-compose exec node sh
$ npm i && npm run build
$ npm run start
> 0times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> 1times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> xtimes
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> ......

and then, open another terminal and execute the following command, 3 seconds after "waiting ...." is displayed.

$ docker-compose restart a b c
> xtimes
> waiting ....
> (node: 4360) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms
> at Timeout.setTimeout [as _onTimeout] (/var/work/node_modules/mongodb/lib/core/sdam/topology.js:878:9)
> at ontimeout (timers.js: 436: 11)
> at tryOnTimeout (timers.js: 300: 5)
> at listOnTimeout (timers.js: 263: 5)
> at Timer.processTimers (timers.js: 223: 10)
> (node: 4360) UnhandledPromiseRejectionWarning: Unhandled promise rejection.This error originated either by throwing inside of an> async function without a catch block, or by rejecting a promise which was not handled with .catch (). (rejection id: 1)
> (node: 4360) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that
> are not handled will terminate the Node.js process with a non-zero exit code.
rvanmil commented 4 years ago

@anzairyo0127 can you try the same with the latest 3.3.3 mongodb library?

anzairyo0127 commented 4 years ago

@rvanmil I can reproduce it in ver3.3.3.

It seems like this error occurs when the mongoDB is in replication configuration and one of the instance (probably the primary instance) receives a command just before it goes down or right after its startup. I think the reason why this happens frequently on MongoDB Atlas is that MongoDB Atlas regularly sends queries to the cluster for monitoring.

longbui99 commented 4 years ago

Any solutions? This problem is ....

vkupar commented 4 years ago

The same problem for more than 1 month and it's not solved yet -_-

octavioamu commented 4 years ago

Updating to mongodb-community@4.2 solved it for me.

crobinson42 commented 4 years ago

@octavioamu Can you provide more specifics? What version of MongoDB database [cluster] were you running prior to 4.2? What version of mongoose and mongodb npm packages are you using and did you upgrade these? How long have you been running 4.2 to be confident that it's solved in this version?

octavioamu commented 4 years ago

sorry don't know what version was installed, probably a very old one since I didn't work with mongo for a while. The mongoose version is on @5.7.7 The message was permanent for me and once I installed the mongodb-community@4.2 (installed via brew) the message stopped.

ahojukka5 commented 4 years ago

If I set {useUnifiedTopology: false} I get an authentication failure

(node:19948) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoError: Authentication failed.]

and if I set {useUnifiedTopology: true}, I get a timeout

(node:20213) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms

The password is definitely correct. This can be reproduced on a local system with the newest versions of everything and LST Node.js. However, using connection string without any kind of authentication seems to be working locally. So if I set e.g. const MONGODB_URI = "mongodb://localhost/fullstack" timeout issue vanishes. Maybe this issue has something to do with authentication? Here's MWE which reproduces the problem on my local setup:

const mongoose = require('mongoose')
// const url = 'mongodb://fullstack:fullstack@localhost/fullstack'
const url = 'mongodb://localhost/fullstack'
console.log('Connection url = ', url, 'connecting')
mongoose.connect(url, { useNewUrlParser: true, useUnifiedTopology: true })
console.log('Connected.')
mongoose.connection.close()

I used the latest Docker image for MongoDB setup.

dameunbite commented 4 years ago

Also happening here. Our production server responds with the bellow message. I gues I will comment useUnifiedTopology for now

MongoDB Connection Options

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Server Log

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Also happening here. Our production server responds with the bellow message. I gues I will comment useUnifiedTopology for now

MongoDB Connection Options

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Server Log

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

I am using mongo db atlas and we are facing the same problem.

dub-tools-jobs: orders - error MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 29 13:16:30 app/worker.1:      at Timeout.setTimeout [as _onTimeout] (/app/node_modules/mongoose/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 29 13:16:30 app/worker.1:     at ontimeout (timers.js:436:11) 
Oct 29 13:16:30 app/worker.1:     at tryOnTimeout (timers.js:300:5) 
Oct 29 13:16:30 app/worker.1:     at listOnTimeout (timers.js:263:5) 
Oct 29 13:16:30 app/worker.1:     at Timer.processTimers (timers.js:223:10) +2m

this all happened with commenting useUnifiedTopology as one recommendation suggested

// mongodb connections
var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    // useUnifiedTopology: true,      
    promiseLibrary: global.Promise
};
newtonEMC2 commented 4 years ago

using mongoose and mongoDB atlas, make sure options are like that: mongoose.connect(DATABASE_URL, { useNewUrlParser: true, useUnifiedTopology: true })

After this, if timeout comes up, u need to whitelist your ip address from mongoDB by going to network access in mongoDB

thefilmmaking commented 4 years ago

Like others, this error crashes my app every few days and I can confirm this is unrelated to access or whitelisting of the ip address.

I am using:

For now, I will be commenting out useUnifiedTopology: true as well. Seems it may be related to either Atlas or mongo, as others have stated.

crobinson42 commented 4 years ago

This is an issue with replica set MongoDB servers and a solution is being worked on here by MongoDB engineers

https://jira.mongodb.org/browse/NODE-2267

@vkarpov15 can probably close this issue because it has nothing to do with Mongoose.

4everglow commented 4 years ago

when your current ip address changes for some reason the connection fails, you should edit it in Network access ip whitelist and use the current ip

mbroadst commented 4 years ago

Hi! My name is Matt and I'm on the drivers team at MongoDB. We're very sorry for the outages y'all have been facing, and I wanted to give a little update on the issue:

We're in the process of trying to phase out our legacy topology types which has turned out to be a very surgical process. Phasing out these types will help greatly reduce the maintenance burden of the driver, and our hope is that means a more stable and efficient driver for our users. In particular, while introducing the "Unified Topology" we did not also introduce the rewrite of the connection pool in an effort to reduce the potential for error. It turns out the connection pool was more tightly coupled to the topology types than we anticipated and as a result we experienced some regressions, particularly around server monitoring.

This morning I pushed a v3.3.4-rc0 of the driver which should address the issues you have been facing. We would be extremely grateful if you could try this version out and report back with your experience. I have left comments on each of the existing tickets related to this issue on NODE-2267, but please feel free to open additional issues there if you experience them.