Summary
SERVER-88399 describes an issue where a mongos is unable to route queries to a replica set secondary after a node is set to hidden: true, and then back to hidden: false. We should add a spec test for this to verify the same case doesn't exist for when drivers try to target replica set members.
The test should do something along the following:
- Spin up a 2-node replica set
- Set read preference to secondaryPreferred
- verify queries are able to target the secondary
- Perform a reconfig to set the secondary to hidden: true
- verify that queries are now routed to the primary only
- Perform a reconfig to set the secondary back to hidden: false
- verify that queries are now routed to the secondary again.
Motivation
So the driver client can properly route nodes to discoverable nodes without having to restart a secondary
Who is the affected end user?
customers, engineers/TSEs who have to diagnose the interesting behavior
How does this affect the end user?
they'll be confused for why their queries are not targeting what they expect
How likely is it that this problem or use case will occur?
It's usually rare for external customers to reconfigure hidden nodes from true to false. However, Atlas may use this sometimes during particular maintenance cases. Atlas currently doesn't currently use this in any existing workflows.
If the problem does occur, what are the consequences and how severe are they?
Certain secondary nodes may not be targeted, which can be an issue for customer workloads.
Is this issue urgent?
Is this ticket required by a downstream team?
None discovered as of reporting.
Is this ticket only for tests?
Depends if the behavior is already correct.
Acceptance Criteria
We confirm the correct behavior and we add the scenario to our continuous testing.
- related to
-
SERVER-88399 A normal secondary with hidden = false couldn't receive query with readPreference = secondaryPreferred
- Backlog