Use Case

As a software engineer using autoConnect  with the MongoClient
I want consistency between calling connect and using autoConnect
So that the client behaves in a predictable manner

User Experience

We are relying on the autoConnect functionality implemented within the Nodejs driver, but we have noticed inconsistencies with how it works when compared to calling connect directly.

The situation we find ourselves in is:

• We run an operation eg insertOne
• An ETIMEDOUT error occurs, or an event occurs that triggers Topology Closed
• We retry the operation
• We encounter a MongoTopologyClosedError
• From this point on the client is unusable unless we explicitly call connect

at processWaitQueue (lib/sdam/topology.js:564:44)
at Topology.selectServer (lib/sdam/topology.js:307:9)
at tryOperation (operations/execute_operation.js:145:33)
at executeOperation (operations/execute_operation.js:75:22)
at Collection.insertOne (lib/collection.js:157:63)
at src/mongo/queue.js:22:69at attempt (src/mongo/helpers.js:506:7)
at src/mongo/helpers.js:522:5at new Promise (<anonymous>)
at retryNetworkTimeout (src/mongo/helpers.js:504:10)
at src/mongo/queue.js:22:13 

And the inconsistency in the driver is noticed here:

In execute_operation, autoConnect is only run if topology is null.

Whereas in mongo_client _connect the driver checks for a null topology or a closed topology before attempting to connect.

To ensure consistent behaviour, the code calling autoConnect as well as autoConnect  itself should also be looking for topology that is null or a topology that is not currently connected.

Dependencies

• upstream and/or downstream requirements and timelines to bear in mind

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
• Is there an opportunity for better cross-driver alignment or testing in this area?
• Is there an opportunity to improve existing documentation on this subject?

Acceptance Criteria

Implementation Requirements

• functional reqs, potential snafus to avoid, performance targets, etc

Testing Requirements

• unit test, spec test sync, etc

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc
• if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward