Mongoose: useUnifiedTopology=true fails when replica node unvailable

[sgpinkus]

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

Bug.

What is the current behavior?

If I try and connect with this MongoDB connection URL and useUnifiedTopology=true:

mongodb://user:xxx@mongo0,mongo1,mongo2/app?replicaSet=rs0&authSource=admin&readPreference=primaryPreferred

Mongoose fails with:

{"name":"MongoNetworkError","errorLabels":["TransientTransactionError"]}

mongo0 is PRIMARY and is up. mongo1 and mongo2 are down. The mongo db shell successfully connects with this string. So this isn't BWC behavior?? Tried a few different options to do with read write concern (ex. readConcern=local&w=0&readPrefernce=primary) but still same error.

If I set useUnifiedTopology=false I get an ugly deprecation warning.

(node:1375) DeprecationWarning: current URL string parser is deprecated, and will be removed in a future version. To use the new parser, pass option { useNewUrlParser: true } to MongoClient.connect.

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

mongoose = require('mongoose');
mongoose.connect(REPLICAS_URL_WITH_UNAVAILABLE_NON_PRIMARIES)

What is the expected behavior?

Connect same way mongo shell does. Don't deny availability to my HA replica set when the primary is available.

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

Mongoose: 5.7.1
MongoDB: 4.2.0
Node: v10.16.3

[yoitsro]

I think this is the correct behaviour - the client shouldn't connect if it is unable to perform all of its actions. In particular, transactions can't work unless the replica set is healthy.

[sgpinkus]

It's different from what mongo shell does, and it's different from the old mongoose behavior too. What's the point in having a replica set if all nodes have to be healthy all the time? Supposedly HA replica set is unavailable when it could provide availability. Providing a specifically requested level of write concern is another matter.

[yoitsro]

I see what you're saying.

Interestingly, there is the option of connectWithNoPrimary, which suggests it'll connect without the primary being available.

There also seems to be some options available specifically related to high availability: ha, haInterval. Have you tried them.

My understanding of a highly available replica set is that unless it is actually highly available, it's not healthy and therefore shouldn't be connected to, at least in production environments.

Alternatively, if you know the specific node you want to connect to, you can just specify that single node in the connection string.

[sgpinkus]

There also seems to be some options available specifically related to high availability: ha, haInterval. Have you tried them.

Yeah it seemed strange to me there is connectWithNoPrimary but not connectWithNoSecondary too. But then I assumed the latter is probably not an option because that is what always happens (or should happen). Haven't tried ha or haInterval. They didn't stand out as relevant, but I will now that you mention them.

---

Update ha=false, haInterval, minSize=1, don't fix issue.

[vkarpov15]

I opened up an issue with the mongodb driver: https://jira.mongodb.org/browse/NODE-2231 . In the meantime, if this is blocking you, please turn useUnifiedTopology off. I'll keep this issue open until we get a fix from the mongodb driver team :+1:

[stieg]

Thanks @vkarpov15

[esetnik]

It looks like mongodb driver version 3.3.3 was released and a fix for NODE-2231 landed. Will mongoose be releasing 5.7.6 soon?

[vkarpov15]

@esetnik we shipped v5.7.6 2 days ago :+1: