Random ReplicaSetNoPrimary errors when using Mongoose

[josh-byster]

Hi,
A little under 5% of requests or so yield the following error, and it seems to only (seemingly randomly) happen sometimes after cold starts and almost always just goes away after a page refresh:

"reason": {
          "errorMessage": "Could not connect to any servers in your MongoDB Atlas cluster. Make sure your current IP address is on your Atlas cluster's IP whitelist: https://docs.atlas.mongodb.com/security-whitelist/.",
          "errorType": "MongooseServerSelectionError",
          "message": "Could not connect to any servers in your MongoDB Atlas cluster. Make sure your current IP address is on your Atlas cluster's IP whitelist: https://docs.atlas.mongodb.com/security-whitelist/.",
          "name": "MongooseServerSelectionError",
          "reason": {
            "compatible": true,
            "heartbeatFrequencyMS": 10000,
            "localThresholdMS": 15,
            "stale": false,
            "type": "ReplicaSetNoPrimary"
          },

The error message is not exactly accurate since I have all IPs whitelisted, however it must have to do with the ReplicaSetNoPrimary.

I connect to Mongoose as follows in my app.js file, which serves as the entrypoint:

mongoose
  .connect(process.env.DB_URI, {
    useUnifiedTopology: true,
    useNewUrlParser: true,
    bufferCommands: false,
    bufferMaxEntries: 0,
    useCreateIndex: true,
  })

Details of the Lambda execution show the following:

Duration: 50.27 ms
Billed Duration: 100 ms
Memory Size: 3008 MB
Max Memory Used: 155 MB
Unknown application error occurred

However, Mongoose has a serverSelectionTimeoutMS defaulted to 30s, so it doesn't seem to make sense why this would spend 50ms and then timeout.

[coetry]

Hi @josh-byster this doesn't look like a Vercel platform error to me, especially since your functions are responding fast (50ms) and still resulting in an error. Have you checked with the MongoDB Atlas folks to see if they know what's going on?

[josh-byster]

Hi @coetry, thanks so much for the response. I've submitted a support ticket just now which details more about the specific issue—essentially I believe this has to do with the fact that the process gets terminated immediately after the response is sent, despite mongoose trying to asynchronously connect to the database.
I've created a test repo to demonstrate this—It only happens with a database that has some latency attached to it (like Atlas), since the connection doesn't happen instantly. If you run it normally using npm start, all works fine (connected handler fires as expected). However, running now dev (or deploying it) with a server with any form of connection latency causes the connecting handler to fire, but never the connected handler, presumably since the serverless function gets cut off as soon as a response gets sent.

This results in a MongoTimeoutError getting thrown and causing likely the error seen above. I think it would be great if somehow it could await that mongo connection before shutting down the lambda, or have some way to prevent prematurely severing the connection to the DB.

[paulogdm]

Perhaps you can tweak the Mongo connection for our serverless environment, as you can see here. If you really need the Mongo connection, consider deploying this app in another platform since Vercel is a static-first solution.

[maxfi]

@josh-byster I'm having the same issue. Did you figure out how to work around this?