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

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

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.

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

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.

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

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

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 (MyAppPathgraphql2node_modulesmongodblibcoresdamtopology.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. (MyAppPathnode_modulesmongodblibcoreconnectionconnection.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)

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)

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.

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.

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?

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.

@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.

Has anyone got around this issue?

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.

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

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

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

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) 

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

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

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

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 [email protected] (which I'll ship in a couple hours) and see if this issue persists.

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?

@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.

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.

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.

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.

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.

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, <
[email protected]> 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
.

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.

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

~This is only an issue with MongoDB Atlas.~

I have a some problem using MongoDB Atlas.

I have the same problem using normal MongoDB.

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'}
> ......



md5-cc5c53b3c0322ef988c85b63b4bb6c4e



$ docker-compose restart a b c



md5-788ff0ed4e46daf35b1b8594351b929f



> 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.

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

@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.

Any solutions? This problem is ....

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

Updating to [email protected] solved it for me.

@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?

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 [email protected] (installed via brew) the message stopped.

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.

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
};

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

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:

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

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.

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.

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

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.

I can confirm the 3.3.4-rc0 has fixed the problem 👍 I will provide more detailed test results later.

after I changed my mongodb version in package.json to
"mongodb": "3.3.4-rc0",
I always get error ( this error does not happen when mongodb version is on 3.3.3):

=============================================
npm ERR! path /tmp/app/node_modules/npm/node_modules/abbrev
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename '/tmp/app/node_modules/npm/node_modules/abbrev' -> '/tmp/app/node_modules/npm/node_modules/.abbrev.DELETE'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent
npm ERR! A complete log of this run can be found in:
npm ERR! /home/vcap/.npm/_logs/2019-11-06T17_19_55_661Z-debug.log
ERROR Unable to build dependencies: exit status 254
Failed to compile droplet: Failed to run all supply scripts: exit status 14
Exit status 223

==================================
my npm version is npm at 6.11.3.

Does this error relate with this new mongodb v3.3.4-rc0 build?

@zhenwan this looks like an issue downloading the abbrev package. My guess is that there are issues with your package-lock.json, please try deleting that file and running npm install again.

I was able to reproduce the error and check if it was solved with the v3.3.4-rc0 driver using the following setup:

• Node.js webserver exposing a simple http api GET /api/todos which queries a todo MongoDB collection which contains some sample data
• Script which calls the api every 500ms running locally on my machine
• Once the script is running, trigger a failover (restart the primary) on MongoDB (on Atlas I was able to do this on an M10 cluster by selecting the "Test Failover" menu option)

The results of this test were as follows:

✅ Mongodb Node.js 3.3.2 useUnifiedTopology false

> MongoDB failover triggered
> MongoDB 'reconnect' event
> A few http calls with +/- 5000ms response times
> MongoDB failover finished
> Everything back to normal

❌ Mongodb Node.js 3.3.2 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'close' event
> Many MongoNetworkError errors
    {
      "name": "MongoNetworkError",
      "stack": "Error: connect ECONNREFUSED <ip_redacted>:27017
          at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1128:14)",
      "errorLabels": [
        "TransientTransactionError"
      ]
    }
> EventEmitter memory leak warning
    (node:18) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 topologyDescriptionChanged listeners added to [NativeTopology]. Use emitter.setMaxListeners() to increase limit
> Many MongoTimeoutError errors
    {
      "name": "MongoTimeoutError",
      "stack": "MongoTimeoutError: Server selection timed out after 30000 ms
          at Timeout._onTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
          at listOnTimeout (internal/timers.js:531:17)
          at processTimers (internal/timers.js:475:7)"
    }
> MongoDB failover finished
> Server unable to recover MongoDB connection
> Server restarted manually
> Everything back to normal

⚠️ Mongodb Node.js 3.3.4-rc0 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'reconnect' event expected but not seen
> A few http calls with +/- 5000ms response times
> A couple failed http calls:
    {
      "name": "MongoError",
      "stack": "MongoError: Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585
          at Connection.<anonymous> (/app/node_modules/mongodb/lib/core/connection/pool.js:451:61)
          at Connection.emit (events.js:210:5)
          at processMessage (/app/node_modules/mongodb/lib/core/connection/connection.js:368:10)
          at TLSSocket.<anonymous> (/app/node_modules/mongodb/lib/core/connection/connection.js:537:15)
          at TLSSocket.emit (events.js:210:5)
          at addChunk (_stream_readable.js:308:12)
          at readableAddChunk (_stream_readable.js:289:11)
          at TLSSocket.Readable.push (_stream_readable.js:223:10)
          at TLSWrap.onStreamRead (internal/stream_base_commons.js:182:23)",
      "ok": 0,
      "errmsg": "Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585",
      "code": 211,
      "codeName": "KeyNotFound"
    }
> MongoDB failover finished
> Everything back to normal

So it seems to work with v3.3.4-rc0, the server is able to recover the connection and resume serving data from MongoDB. There are still two issues though:

• The 'reconnect' event seems to be missing
• A couple requests fail with a "Cache Reader No keys found for HMAC that is valid for time" error message

@mbroadst yes, deleting package-lock.json solved my missing file issue.

But I still get the error:
2019-11-06T12:52:10.35-0600 [CELL/0] OUT Container became healthy
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR /home/vcap/app/node_modules/connect-mongo/src/index.js:135
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR throw err
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR ^
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR Error: Server selection timed out after 30000 ms
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR at Timeout.setTimeout [as _onTimeout] (/home/vcap/app/node_modules/connect-mongo/node_modules/mongodb/lib/core/sdam/topology.js:878:9)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR at ontimeout (timers.js:469:11)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR at tryOnTimeout (timers.js:304:5)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR at Timer.listOnTimeout (timers.js:264:5)
2019-11-06T12:52:39.35-0600 [APP/PROC/WEB/0] OUT Exit status 1

@zhenwan it looks like it might be related to not being able to connect to your cluster on initial connect. Also your backtrace to topology.js:878 curiously does not point to a place where an error is generated, nor are you receiving the correct type MongoTimeoutError.

Can you please open a new jira ticket so we can triage your particular case. It looks like we'll need more detail than what you've pasted here. Thank you!

@mbroadst
Thanks for helping fix the issue. I just want to say, using v3.3.4-rc0 is not solving my problem. I'm still getting this message

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout (api/node_modules/mongodb/lib/core/sdam/topology.js:899:9)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

In my case, I'm using loopback-connector-mongodb, but I setup my package.json to force using last version of mongodb in resolutions as follow

"resolutions": {
    "mongodb": "^3.3.4-rc0"
  }

my connection parameters as follow

"host": "127.0.0.1",
 "port": 27017,
"database": "***",
"password": "***",
"user": "***",
"authSource": "***",
"useNewUrlParser": true,
"enableGeoIndexing": true

below is my environment parameters

MongoDB server version: 3.6.3 on localhost
yarn v1.19.1
node v8.16.2 

Thanks in advance

update
I also tried to add useUnifiedTopology: true to connection parameters, but got same result.

Another confirmation here, from someone using mongoose directly, that useUnifiedTopology: false works for me.

@mbroadst thank you for the update from MongoDB's end. Excuse my ignorance, but will the aforementioned fix in mongodb v3.3.4-rc0 cascade down to mongoose at some point? Slightly uncomfortable with the idea of embracing deprecated features as a workaround in a prod environment.

@mmmmoj similar to @zhenwan's question above, your stack trace seems to indicate you are not in fact running v3.3.4-rc0. Maybe try removing your package-lock.json? Can you please file a jira ticket so we can delve into the specifics of your case.

@bigsee (man GitHub does _not_ like autocompleting your name!) Glad to hear it works for you, and you're welcome for the update - our community is very important to us. I'll let @vkarpov15 speak for the timing of the release, but we work closely and I'm sure he's interested in fixing this for y'all :)

@mbroadst
done! Thanks
NODE-2313

@mbroadst ha! sorry for the awkward name!

it turns out I might have spoken too soon, perhaps given the random nature of the error appearing. On a cold start of my app, along with the expected deprecation warning, I now see this slightly scarier error in the logs:

Unhandled rejection: { MongoNetworkError: failed to connect to server [myserver.mlab.com:55841] on first connect [{ MongoNetworkError: connection 0 to myserver.mlab.com:55841 timed out
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:335:7)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:420:8)
    at ontimeout (timers.js:482:11)
    at tryOnTimeout (timers.js:317:5)
    at Timer.listOnTimeout (timers.js:277:5) name: 'MongoError', [Symbol(mongoErrorContextSymbol)]: {} }]
    at Pool.<anonymous> (/var/task/node_modules/mongodb/lib/core/topologies/server.js:431:11)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at connect (/var/task/node_modules/mongodb/lib/core/connection/pool.js:580:14)
    at callback (/var/task/node_modules/mongodb/lib/core/connection/connect.js:109:5)
    at provider.auth.err (/var/task/node_modules/mongodb/lib/core/connection/connect.js:352:21)
    at _authenticateSingleConnection (/var/task/node_modules/mongodb/lib/core/auth/auth_provider.js:66:11)
    at sendAuthCommand (/var/task/node_modules/mongodb/lib/core/auth/scram.js:177:16)
    at Connection.errorHandler (/var/task/node_modules/mongodb/lib/core/connection/connect.js:321:5)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:333:10)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
  name: 'MongoNetworkError',
  errorLabels: [ 'TransientTransactionError' ],
  [Symbol(mongoErrorContextSymbol)]: {} }

It used to be MongoTimeoutError but now it's MongoNetworkError... ...any ideas?

@bigsee that error would indicate that you are _not_ using the unified topology. Please enable it by passing useUnifiedTopology: true to your MongoClient

@mbroadst that's correct, which I believe is the point of this issue. Apologies if I'm wrong on that.

When I pass useUnifiedTopology: true the deprecation warning disappears but my app randomly crashes with the title error of this issue MongoTimeoutError: Server selection timed out after 30000 ms.

As with @vkarpov15 and others above, I have not been able to reproduce this issue consistently. The error happens a few times a day resulting in 502 and horrible UX from time to time errors. It seems to be a new issue.

As reported above, the workaround of setting useUnifiedTopology: false (or commenting out) prevents the error in this issue, but restores the deprecation warning and now the slightly scarier MongoNetworkError above. As an aside, this doesn't actually kill my app but does worry me that it will for a user at some point.

@bigsee the MongoNetworkError you are experiencing is not new, and it means that the driver was unable to make an initial connection to a cluster (incidentally if some sort of race condition between your app starting and your cluster starting is causing this, then the unified topology should help here as well).

The point of this issue is that people were following the guidance to use the unified topology, and when they did they were experiencing spurious timeout errors. v3.3.4-rc0 was released to address that specific issue, so the current guidance is to use that version which should remove the deprecation notice and correct the spurious timeout issues people have encountered.

I should also say: this version will not prevent _all_ timeout errors. That error is being caused by the driver's inability to do an initial connect to a cluster, which would indicate some sort of configuration (connection string) or network error on your part. With the unified topology this will show up as a MongoTimeoutError with a reason field indicating the network error that caused the timeout on initial connect.

@mbroadst I didn't mean to suggest that the MongoNetworkError was new in my last comment, so apologies if that is how it read. It's the `MongoTimeoutError that is new. To hopefully be clearer, this has been my process:

1. app has config with useUnifiedTopology: true - everything working as expected
2. app starts randomly crashing and presents with a MongoTimeoutError matching the title of this issue, as well as the first few lines of a stack trace presented above
3. a Google / SO search eventually brings me here
4. I use useUnifiedTopology: false workaround suggested
5. the MongoTimeoutError error disappears along with the crashing of the app. however, it is replaced by the deprecation warning initially. then, later, by a additional MongoNetworkError not seen in the application before setting useUnifiedTopology: false

Perhaps, as you suggest, this is correlation rather than causation. Just seemed like a smoking gun to me. At least the app is not crashing now. I'm just worried about leaving an option that is deprecated.

@bigsee Ah! Sorry, I misread your original comment to mean that you were confirming that the v3.3.4-rc0 bug fixes resolved your issues from v3.3.3. Have you had a chance to try the new version?

This is my first trial on Mongodb and I'm having this error. read through the comments and changed my db to v3.3.4-rc0 and it didn't still fix the error

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.
MongoNetworkError: failed to connect to server [cluster0-shard-00-00-rhdve.mongodb.net:27017] on first connect [MongoNetworkError: connection 3 to cluster0-shard-00-00-rhdve.mongodb.net:27017 closed
at TLSSocket. (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js:356:9)
at Object.onceWrapper (events.js:297:20)
at TLSSocket.emit (events.js:209:13)
at net.js:588:12
at TCP.done (_tls_wrap.js:479:7) {
name: 'MongoNetworkError',
errorLabels: [Array],
}]
at Pool. (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoretopologiesserver.js:433:11)
at Pool.emit (events.js:209:13)
at C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js:562:14
at C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js:999:9
at callback (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:109:5)
at C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:129:7
at Connection.errorHandler (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:321:5)
at Object.onceWrapper (events.js:297:20)
at Connection.emit (events.js:209:13)
at TLSSocket. (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js:354:12) {
name: 'MongoNetworkError',
errorLabels: [ 'TransientTransactionError' ],
}
TypeError: Cannot read property 'find' of undefined
at C:laragonwwwVue-express-mongodbserverroutesapiposts.js:12:26

@Syfon01 the error you are experiencing is because of some sort of configuration error, the driver is using the legacy topology and failing to make its initial connection to a cluster after a default of 10s. Please check your connection string and network configuration and verify that you are able to connect to the cluster (perhaps with the mongo shell). If you're still experiencing issues, please open a jira ticket so we can continue conversation there, and not confuse people looking at this GitHub issue

For people who are having this issue , if you are using Mongo Atlas Cloud Instance , Please see if you are having your IP address specified correctly in the Network Access tab.

I had the issue and it seems that since my ISP gives out New IPs everytime (DHCP) i reconnect to the network , Mongo Atlas was only white listing the previously specified IP address. Hope this helps someone.

update - doesn't work

I was able to solve this issue by changing the structure of my code, specifically the callback as follows:

mongoose.connect(DATABASE_URL, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
}).then(() => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`)
    });
}).catch(err => console.log(err));

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, () => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    });
}).catch(err => console.log(err));

@mtn2bay that doesn't make any sense you basically used the callback function instead of the promise, the result is still one and the same, the only difference is that in the callback function you get both the connection and the error in the callback function which you're not logging instead of relying on .then and .catch, so your function is logging connected to db and starting the app either way even if there's an error. try this instead

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, (err, connection) => {
if(err) {
console.error(err)
return
}    
console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    })

@khaledosman thank you for the correction. You are right, I was just ignoring the error rather than addressing it. I actually had an issue with my db path.

i was facing the same issue, i updated mongoose npm package from 5.6.9 to 5.7.6 and the issue vanished.

For people who are having this issue , if you are using Mongo Atlas Cloud Instance , Please see if you are having your IP address specified correctly in the Network Access tab.

I had the issue and it seems that since my ISP gives out New IPs everytime (DHCP) i reconnect to the network , Mongo Atlas was only white listing the previously specified IP address. Hope this helps someone.

solved my issue
UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms at Timeout.setTimeout (C:\Users\Umer MIB\Desktop\Chatbots2\mongobot\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:4304) 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:4304) [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

I do not know how that solved a problem, but I downloaded Compass and connected it to database, just copied the link. Once it got connected, the error was gone. Topology is still true in my code. Maybe it configured some options with Compass that were not right with usual mongodb installation. Now I can connect without Compass and all seems to work, just did it once in the beginning.

I got the same issue and thanks to this forum, got through by commenting useUnifiedTopology setting. However then I uncommented this setting, but now it still works just fine... quite confused...

Mongoose v5.7.11 uses the newly release MongoDB driver 3.3.4, so I'm going to close this issue. If you're getting a similar error message, please open up a new issue and follow the issue template.