[DRIVERS-946] Change SDAM "not master" and "node is recovering" to match the server's NotPrimary and Shutdown error categories Created: 04/Feb/20  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: SDAM
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Shane Harvey Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Driver Changes: Not Needed

 Description   

The server defines the NotPrimaryError category as:

  • InterruptedDueToReplStateChange
  • NotMasterOrSecondary
  • PrimarySteppedDown
  • NotMaster
  • NotMasterNoSlaveOk

And the ShutdownError category as:

  • InterruptedAtShutdown
  • ShutdownInProgress

https://github.com/mongodb/mongo/blob/r4.9.0-alpha/src/mongo/base/error_codes.yml#L10

The SDAM spec however defines "not master" as:

  • NotMaster
  • NotMasterNoSlaveOk

And "node is recovering" as:

  • InterruptedAtShutdown
  • InterruptedDueToReplStateChange
  • NotMasterOrSecondary
  • PrimarySteppedDown
  • ShutdownInProgress

I propose that we change SDAM's definitions to match the server's and rename "not master" and "node is recovering" to NotPrimaryError and ShutdownError respectively. This change will also allow us to replace the SDAM "node is shutting down" error with ShutdownError.



 Comments   
Comment by Shane Harvey [ 04/Feb/20 ]

This change might also require a change to the wording of single-threaded behavior in "not master" and "node is recovering":

For single-threaded clients, in the case of a "not master" or "node is shutting down" error, the client MUST mark the topology as "stale" so the next server selection scans all servers. For a "node is recovering" error, single-threaded clients MUST NOT mark the topology as "stale". If a node is recovering for some time, an immediate scan may not gain useful information.

This seems to be the only place that "node is recovering" is used independent of "not master".

Generated at Thu Feb 08 08:22:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.