Skip to content

Conversation

nbbeeken
Copy link
Contributor

@nbbeeken nbbeeken commented Oct 4, 2025

Description

Summary of Changes

  • Remove the credentials requirement for running the server selection and checkout steps of connect
    • This is to make the fail and success conditions consistent for all topologies and environments.
  • Move the server selection step into the skipPingOnConnect section so that auto-connect no longer runs a duplicate server selection (since it is going to run one to service the operation anyway)
  • Correct tests for new behavior
Notes for Reviewers
  • The unified test runner is now able to run the spec tests for server selection which identified an issue with translating the ReadPreference schema defined in the unified spec to our type.
    • mode capitalization was different
    • tagSets instead of tags
  • The find cursor abort test is flipped from its previous assertion, but this seems "more correct". We will now verify the connect-ability of the server before entering the section where the abortSignal's abort state would be evaluated.
  • Now that checkOut/checkIn is being called in more places, we need a few empty stubs of it where previously we only empty stubbed serverSelection

What is the motivation for this change?

Make connect's API consistent in all environments as a fail-fast mechanism for preparing a MongoClient for use within an application. In our particular case this is compass/mongosh/vscode which shares a common wrapping around client.connect that all those upstream projects expect certain invariants to be true if connect returns successfully. These include: Auth is configured correctly, hostnames are correct, SRV has been resolved, and TLS is setup correctly.

Release Highlight

Improve MongoClient.connect() consistency across environments

The MongoClient connect function will now run a handshake regardless of credentials being defined. The upshot of this change is that connect is more consistent at verifying some fail-fast preconditions regardless of environment. For example, previously, if connecting to a loadBalanced=true cluster without authentication there would not have been an error until a command was attempted.

Additionally, when calling an operation method (find, insertOne, etc.) right away (a.k.a auto-connecting your client) the MongoClient will no longer run two server selections (one for connect, one for the operation) instead only the one for the operation will be performed.

Double check the following

  • Lint is passing (npm run check:lint)
  • Self-review completed using the steps outlined here
  • PR title follows the correct format: type(NODE-xxxx)[!]: description
    • Example: feat(NODE-1234)!: rewriting everything in coffeescript
  • Changes are covered by tests
  • New TODOs have a related JIRA ticket

Comment on lines +207 to +209
if (session?.snapshotEnabled && !topology.capabilities.supportsSnapshotReads) {
throw new MongoCompatibilityError('Snapshot reads require MongoDB 5.0 or later');
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that server selection may not run above, we have stale "supportsSnapshotReads" information, however, this is always been true when relying upon this value before running server selection which may trigger monitoring checks to get the latest topology info.

* @param options - Optional configuration options for the client
*
* @see docs.mongodb.org/manual/reference/connection-string/
* @see https://www.mongodb.com/docs/manual/reference/connection-string/
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dunno if this matters but I get redirected when I visit the original, so figured we could skip the redirect?

Comment on lines +869 to +873
const error = await client
.db()
.collection('test')
.insertOne({ a: 1 }, { timeoutMS: 500 })
.catch(error => error);
Copy link
Contributor Author

@nbbeeken nbbeeken Oct 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is a bit weird but maybe this is just a test clean up? Auto-connect has not started respecting timeoutMS with this change, rather insertOne is now paying the cost of being the first to select a server, which we simulate with sinon, generally the first serverSelection in a MongoClient's lifecycle is going to be the slowest as discovery is run.

So this is correct for the change we're making, the bit about not double server selecting, but the outcome is that auto-connecting operations are now subject to the higher cost of discovery (which can also be true for any operation at any time, but arguably less likely).

Citing our docs:

If you need predictable operation timing with timeoutMS, call connect explicitly before performing operations.

I think this change makes sense and I can make it clear in the release notes here.

Comment on lines +12 to +14
'Failed client bulkWrite operation: log messages have operationIds',
'Successful bulkWrite operation: log messages have operationIds',
'Successful client bulkWrite operation: log messages have operationIds'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old bulkWrite we knew we didn't have operationId support but by nature of copying out Node.js specific versions of these tests did we miss adding support to client.bulkWrite too? I have not looked into what it is or does, so maybe it doesn't fit into our API well.

@nbbeeken nbbeeken marked this pull request as ready for review October 4, 2025 22:45
@nbbeeken nbbeeken requested a review from a team as a code owner October 4, 2025 22:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant