Summary

As mentioned in DRIVERS-561, the SRV polling specification currently disallows non-sharded clusters from participating in dynamic reconfiguration of the client's topology on SRV record canges:

This feature is only available when the Server Discovery has determined that the TopologyType is Sharded, or Unknown. Drivers MUST NOT rescan SRV DNS records when the Topology is not Sharded (i.e. Single, ReplicaSetNoPrimary, or ReplicaSetWithPrimary).

In practice, we've hit a few issues wherein we are using MongoDB Atlas with a non-sharded cluster, behind PrivateLink endpoints. On occasion, the private endpoints need to be updated or changed. When this happens, many of our NodeJS applications start failing and never recover due to the aforementioned limitations.  The only solution is to restart the application, which reduces availability and introduces operational overhead to resolve. 

Ideally, non-sharded clusters could benefit from the current dynamic updates from polling the SRV records for changes.

Motivation

Who is the affected end user?

Users who use non-sharded clusters and who make changes to SRV while applications are running.

How does this affect the end user?

Are they blocked? Are they annoyed? Are they confused?

Loss of application availability and increased operational effort to resolve.

How likely is it that this problem or use case will occur?

The likelihood is reasonably high for users that have many environments which change their infrastructure or perform migrations frequently.

If the problem does occur, what are the consequences and how severe are they?

It is very difficult to debug as its not clear in the logs. This required consultation with MongoDB Atlas experts in order to troubleshoot.

Is this issue urgent?

Not urgent, but highly desired.

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

No

Acceptance Criteria

SVR polling and resolution semantics is available for non-sharded clusters.

The following is an (untested) example of how this might be able to be achieved today using the NodeJS native driver:

// Create client with SRV+seedlist connection string
const uri = "mongodb+srv://<prefix>.mongodb.net/auth0?retryWrites=false&appName=server";
const client = new MongoClient(uri);
 
// Connect to the MongoDB cluster
await client.connect();

// As a workaround for https://github.com/mongodb/specifications/blob/master/source/polling-srv-records-for-mongos-discovery/polling-srv-records-for-mongos-discovery.rst#implementation
// See https://jira.mongodb.org/browse/DRIVERS-561
const srvPoller = client.s.srvPoller;

// Could be undefined non-SRV-based config so we shouldn't assume generally
if (srvPoller) {
  // Reproduce what happens for sharded clusters in Topology#detectShardedTopology
  srvPoller.on(SrvPoller.SRV_RECORD_DISCOVERY, client.s.detectSrvRecords);
  srvPoller.start();
}

However, as noted this uses internal implementation details that may  change on subsequent releases. Thus, first class support is preferred.