[SERVER-84763] Confirm agent behavior with updated getClusterParameter semantics with embedded routers Created: 11/Jan/24  Updated: 11/Jan/24  Resolved: 11/Jan/24

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Dennis Kuczynski Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

See SERVER-83421

From George

today, when we run getClusterParameter on any mongod, the value can be stale or 'ahead' of an update (i.e. roll-backable). When we run it on mongos, the value can only be stale of what is majority-commmitted on every shard + the CSRS, and any change it observes can't be rolled-back

i'm wondering if the second semantic is important to preserve from the automation persepctive. I think the answer might be no because if we consider setting a cluster parameter from A to B and back to A, it's possible for the router to not see B entirely, and when get returns A, there's no way of knowing if it's the first or second


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