Use Case

As a... Node.js driver user
I want... connect's latency to be reduced
So that... I move on to meaningful commands as quickly as possible

User Experience

• What is the desired/expected outcome for the user once this ticket is implemented?
  • connect does not wait for a primary to be discovered to run a handshake

Dependencies

• COMPASS-9455

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
  • Is connect's defaulting to primary necessary?
  • Does it provide meaning (like writability) that is relied upon by users?
  • What does it mean when a user changes the RP at the client level?
  • How does this impact other topologies?
  • Should users be able to configure connect's RP separately from the client one? Does the methodology here line up with timeoutMS? (ex. do not configure, do not inherit?)
• Is there an opportunity for better cross-driver alignment or testing in this area?
  • No, other drivers don't have connect (generally)
• Is there an opportunity to improve existing documentation on this subject?
  • Yes, connect should clarify what it's guarantees are

Acceptance Criteria

Implementation Requirements

• Update the readpreference to nearest in connect

Testing Requirements

• The driver should checkout a connection after the first node replies rather than waiting for the primary.

Documentation Requirements

• connect API docs

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