-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Component/s: Server Selection
-
None
-
Needed
Summary
Server selection supports deprioritizing servers on retries for sharded clusters. This functionality is being expanded to run on all topologies.
For some drivers, the spec changes might be minimal. For some, like Node, it requires some refactoring of server selection logic. Regardless of the effort of implementation, it seems feasible and prudent to add tests for the deprioritization logic for each topology type.
Motivation
Who is the affected end user?
Who are the stakeholders?
How does this affect the end user?
Are they blocked? Are they annoyed? Are they confused?
How likely is it that this problem or use case will occur?
Main path? Edge case?
If the problem does occur, what are the consequences and how severe are they?
Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?
Is this issue urgent?
Does this ticket have a required timeline? What is it?
Is this ticket required by a downstream team?
Needed by e.g. Atlas, Shell, Compass?
Is this ticket only for tests?
Does this ticket have any functional impact, or is it just test improvements?
Acceptance Criteria
- Clarify that drivers MUST apply server deprioritization for all topology types in server selection.
- Clarify that deprioritized servers is a list of deprioritized servers (see
DRIVERS-2901for context) - Update the server selection test framework to support testing with a list of deprioritized servers.
- Add tests ensuring that drivers correctly prioritized non-deprioritized servers across all topology types.
- is duplicated by
-
DRIVERS-2901 Clarify the intent behind the list of deprioritized mongos'es and fix the pseudocode
-
- Closed
-
- is related to
-
DRIVERS-2901 Clarify the intent behind the list of deprioritized mongos'es and fix the pseudocode
-
- Closed
-