[SERVER-40860] Including a "txnNumber" field on a command using "linearizable" read concern will bypass post-execution read concern wait Created: 26/Apr/19  Updated: 08/May/19  Resolved: 08/May/19

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

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

Issue Links:
Duplicate
duplicates SERVER-41050 Ban txnNumbers outside of transaction... Closed
Related
related to SERVER-40850 Read commands that check out the sess... Closed
Operating System: ALL
Steps To Reproduce:

 
const name = "linearizable_read_txnNum";
const replTest = new ReplSetTest({
    name: name,
    nodes: 1,
});
replTest.startSet();
replTest.initiate();
 
const dbName = name;
const collName = "coll";
 
let primary = replTest.getPrimary();
const session = primary.startSession({causalConsistency: false});
const sessionDb = session.getDatabase(dbName);
const sessionColl = sessionDb[collName];
 
// Insert a doc.
assert.commandWorked(sessionColl.insert({x:1}));
 
jsTestLog("Running find command.");
let res = sessionDb.runCommand({
    find: collName,
    readConcern: {level: 'linearizable'},
});
counters = primary.adminCommand({serverStatus: 1}).opReadConcernCounters;
assert.eq(counters.linearizable, 1);
 
res = sessionDb.runCommand({
    find: collName,
    readConcern: {level: 'linearizable'},
    txnNumber: NumberLong(1)
});
counters = primary.adminCommand({serverStatus: 1}).opReadConcernCounters;
// This assertion will fail if we don't do a proper 'linearizable' read above.
assert.eq(counters.linearizable, 2);
 
 
replTest.stopSet();

Sprint: Repl 2019-05-20
Participants:
Linked BF Score: 10

 Description   

If you run a read command on a session (e.g. 'find') at "linearizable" read concern and include a "txnNumber" field, the server will do no waiting to satisfy the linearizable read concern i.e. it will bypass the call to waitForLinearizableReadConcern. This is due to the fact that when we check out a session, which we will do when a command includes a txnNumber, we read from the transactions table inside a DBDirectClient query. The DBDirectClient overrides the original read concern on the OperationContext and so at the end of command execution, we will not wait on any read concern.



 Comments   
Comment by William Schultz (Inactive) [ 29/Apr/19 ]

If drivers never attach a txnNumber to read commands, this may not necessarily need to be fixed. We could arguably consider this an undefined behavior.

Comment by William Schultz (Inactive) [ 26/Apr/19 ]

This is a specific instance of a potentially more general issue with the fact that DBDirectClient queries appear to override the read concern of the OperationContext given to it. In the service entry point, we extract read concern from the command object and update the read concern of the OperationContext here. There is no exclusion for direct client queries unless the parent operation is running under "kSnapshotReadConcern".

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