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.