[SERVER-39660] AutoGetCollectionForRead should throw with SnapshotUnavailable if provided timestamp is earlier than minimum visible snapshot Created: 19/Feb/19  Updated: 29/Oct/23  Resolved: 25/Mar/19

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

Type: Bug Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-39169 Add testing-only support for doing sn... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

//
// Run with: python buildscripts/resmoke.py --suites=jstestfuzz_replication_session repro.js
//
 
res = db.test.runCommand("insert", {
    documents :[{x:1}]
});
let operTime = res.operationTime;
 
// Works.
res = db.runCommand({
    find: "test",
    sort: {_id: 1},
    $_internalReadAtClusterTime: operTime,
});
assert.commandWorked(res);
 
// Causes invariant failure.
res = db.runCommand({
    find: "test",
    sort: {_id: 1},
    $_internalReadAtClusterTime: Timestamp(operTime.getTime()-1, operTime.getInc()),
});

Sprint: Repl 2019-03-25, Repl 2019-04-08
Participants:
Linked BF Score: 53

 Description   

Since the addition of the $_internalReadAtClusterTime field in SERVER-39169, it is possible for a 'find' command to do a read at a timestamp specified by the client. This means that when taking locks inside the AutoGetCollectionForRead constructor it is possible to be using a kProvided read source where the given timestamp is earlier than the minimum visible snapshot for the collection. If this is the case, then we will run past this logic and continue on to trigger this invariant. Instead of triggering an invariant in this case, we should throw an exception with a SnapshotUnavailable error, analogous to the behavior of dbHash command.



 Comments   
Comment by Githook User [ 08/Apr/19 ]

Author:

{'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}

Message: SERVER-39660 Move readSource re-definition to a clearer location in AutoGetCollectionForRead
Branch: master
https://github.com/mongodb/mongo/commit/73e719a1ee1c174a3131e19b537b3ae8aa958dad

Comment by Githook User [ 25/Mar/19 ]

Author:

{'email': 'william.schultz@mongodb.com', 'name': 'William Schultz', 'username': 'will62794'}

Message: SERVER-39660 Return SnapshotUnavailable error when trying to read behind pending catalog changes in AutoGetCollectionForRead using a provided timestamp read source
Branch: master
https://github.com/mongodb/mongo/commit/cdc1359a61de42673455c4f64eb9986da5ef0df4

Comment by Max Hirschhorn [ 19/Feb/19 ]

Returning a SnapshotUnavailable error response in the dbHash command was something I had adapted from the logic in AutoGetCollectionForRead back when I was doing SERVER-34778. It looks like the changes from 91504c8 as part of SERVER-34572 move it to AutoGetCollection. Maybe things would "just work" if it wasn't tied to repl::ReadConcernLevel::kSnapshotReadConcern and also took into account RecoveryUnit::ReadSource::kProvided?

Generated at Thu Feb 08 04:52:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.