-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Replication
-
Fully Compatible
-
152
In "store_retryable_find_and_modify_images_in_side_collection.js" we check that retrying a write command that already succeeded returns the same response, including the 'operationTime' field.
SERVER-78115 (e806861) made a change such that retrying a succeeded write command may still advance the operationTime since it introduces a noop write in some cases. This commit caused above test to fail frequently.
While SERVER-78115 is being reverted, there is a question that if the test should check 'operationTime' being identical for retryable writes.
From this doc, it seems that the 'operationTime' returned from a operation that doesn't write oplog (e.g. retry of a succeed write) can be arbitrary if any other clients or background writers advances the oplog, since in this case the returned 'operationTime' is just the top of the majority committed oplog. That seems to suggest that the 'operationTime' in a retry attempt of a succeeded write is not guaranteed to be same as the original one.
- is related to
-
SERVER-78115 Shard primaries must commit a majority write before using new routing information from the config server
- Closed
- related to
-
SERVER-80183 Remove operationTime check from store_retryable_find_and_modify_images_in_side_collection.js
- Closed