[SERVER-48459] Race in non_transaction_snapshot_reads_retry.js Created: 28/May/20  Updated: 29/Oct/23  Resolved: 01/Jun/20

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

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: A. Jesse Jiryu Davis
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2020-06-01
Participants:
Linked BF Score: 22

 Comments   
Comment by A. Jesse Jiryu Davis [ 01/Jun/20 ]

In the old code:

  1. insert a document at timestamp insertTS
  2. start a snapshot read, expect it to select insertTS as the read timestamp
  3. block the read with a failpoint
  4. wait minSnapshotHistoryWindowInSeconds
  5. update the document at timestamp updateTS
  6. unblock the read
  7. expect the read to get SnapshotTooOld, retry with a new timestamp >= updateTS
  8. assert that we read the updated document

However, between steps 1 and 2 it's possible for some other write to occur at timestamp T. (Lingzhi noticed that in the build failure, a config server finished building an index on a config colleciton, which advanced the clusterTime.) Then at step 2 we select T for the read timestamp. Sometimes this is possible:

insertTS < history expiration time < T < updateTS

At step 7, the read proceeds with timestamp T, which is still valid. There is no SnapshotTooOld error, and we retrieve the version of the document before it was updated, and the test fails.

The new code sleeps after updating the document instead of before, to ensure that the oldest valid read timestamp is >= updateTS.

Comment by Githook User [ 01/Jun/20 ]

Author:

{'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}

Message: SERVER-48459 Race in non_transaction_snapshot_reads_retry.js
Branch: master
https://github.com/mongodb/mongo/commit/d66e21d57074813fc49eaca1e91e7c98ed302a75

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