[SERVER-51689] _configsvrCommitSplitChunk is not waiting for opTime on early return Created: 16/Oct/20  Updated: 29/Oct/23  Resolved: 26/Oct/20

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

Type: Bug Priority: Major - P3
Reporter: Marcos José Grillo Ramirez Assignee: Pierlauro Sciarelli
Resolution: Fixed Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2020-11-02
Participants:
Linked BF Score: 26

 Description   

If a command on the config server performs an early return without doing a write, it is expected that they will setLastOpToSystemLastOpTime (like commitChunkMerge) that way it is ensured that future reads will see the changes majority committed by previous operations.

When committing a chunk split the original chunk is searched, and if not found, then an error is returned, however, the following scenario might happen:

1. A _configsvrcommitSplitChunk is sent from a shard
2. The connection drops but the commit is successful on the primary
3. The command is retried but it returns early
4. Another split command is issued
5. The collection metadata is refreshed

Step 5 might not see the changes committed on 3 because if the changes haven't been majority written by the time the refresh happens, the effects of the split will not be seen on the shard if a non primary node is queried, causing a precondition failure (the range determined on the router is the precondition sent later on) on the next applyOps.



 Comments   
Comment by Githook User [ 26/Oct/20 ]

Author:

{'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}

Message: SERVER-51689 _configsvrCommitSplitChunk is not waiting for opTime on early return
Branch: master
https://github.com/mongodb/mongo/commit/c33f06f6e747049891f7cd5f5a1a7147dbb4e313

Generated at Thu Feb 08 05:26:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.