[SERVER-79483] Investigate if tests should check operationTime being identical for retryable write responses Created: 28/Jul/23  Updated: 17/Aug/23  Resolved: 17/Aug/23

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

Type: Task Priority: Major - P3
Reporter: Wenbin Zhu Assignee: Allison Easton
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-80183 Remove operationTime check from store... Closed
is related to SERVER-78115 Shard primaries must commit a majorit... Closed
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Participants:
Linked BF Score: 152

 Description   

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.
 



 Comments   
Comment by Allison Easton [ 17/Aug/23 ]

Great, thank you both! I have opened SERVER-80183 to update the test.

Comment by Jason Chan [ 16/Aug/23 ]

Thanks for thinking about this allison.easton@mongodb.com, I think you're right that it should be safe to change the test to omit checking opTime. I think the only thing we care about in regards to findAndModify is that the timestamp field in the imageEntry itself consistently matches the timestamp component of the lastWriteOpTime field for the sessions transactions entry in the config.transactions table. Basically, I don't think there's anything specific about retryable findAndModify's that would make it have different semantics around the response operationTime from other retryable operations.

The test was probably passing simply because we weren't expecting to do any background writes to the database and that seems to have changed lately.

Comment by Wenbin Zhu [ 16/Aug/23 ]

I think that makes sense to me, but I'd like to double check with jason.chan@mongodb.com.

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