-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
Fully Compatible
-
ALL
-
Cluster Scalability 2024-1-8, Cluster Scalability 2024-1-22
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
Under PM-3190, as reported by kaitlin.mahar@mongodb.com verbatim:
- we have two shards, shardA and shardB, and send the write to them both
- shardA responds {ok: 1, n:0, writeConcernError: {…}} and we save that write concern error
- shardB responds with a StaleConfig error for the write.
- given the StaleConfig error, we consider the response we got from shardA in step 2 to be out of date/invalidated, and so we retarget all shards anew.
- after retargeting, say we get {{
{ok:1, n:1}
}} back from shardA and {{
{ok:1, n:0}}} back from shardB
- the final response, perhaps confusingly, is still going to contain the write concern error from step 2, even though we consider that write irrelevant at this point and ended up redoing it (and didn’t get a WC error the second time.)