[SERVER-40850] Read commands that check out the session and use speculative majority read concern may hit invariant inside DBDirectClient call 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:
Depends
Duplicate
duplicates SERVER-41050 Ban txnNumbers outside of transaction... Closed
Related
is related to SERVER-40860 Including a "txnNumber" field on a co... Closed
Operating System: ALL
Steps To Reproduce:

const name = "bf-12790_repro";
const replTest = new ReplSetTest({
    name: name,
    nodes: [{}],
    nodeOptions: {enableMajorityReadConcern: 'false'}
});
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];
 
// Triggers invariant.
let res = sessionDb.runCommand({
    find: collName,
    readConcern: {level: 'majority'},
    allowSpeculativeMajorityRead: true,
    txnNumber: NumberLong(1)
});
 
replTest.stopSet();

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

 Description   

Running a speculative majority read command that checks out the session (by, example, including a 'txnNumber') may hit this invariant when trying to read from the transactions table via DBDirectClient here, which may be called when we check out a session. We may be able to fix this by returning immediately inside waitForSpeculativeMajorityReadConcern if we are inside a direct client.



 Comments   
Comment by Tess Avitabile (Inactive) [ 08/May/19 ]

Thank you!

Comment by Kaloian Manassiev [ 08/May/19 ]

Confirming for MongoS there should never be a case where txnNumber is attached for anything that's not a transaction or write commands with retryable writes. If there are any (which I am not aware of) that would be a bug.

Comment by Tess Avitabile (Inactive) [ 08/May/19 ]

Thanks, shane.harvey!

kaloian.manassiev, can you confirm this for mongos?

Comment by Shane Harvey [ 06/May/19 ]

Yes, drivers only send txnNumber with retryable writes and transactions.

Comment by Tess Avitabile (Inactive) [ 06/May/19 ]

shane.harvey, kaloian.manassiev, we are interested in banning txnNumbers outside of retryable writes and multi-document transactions. That is, a command may only have a txnNumber if it is a retryable write command or autocommit:false is specified. We don't test txnNumbers outside of retryable writes and multi-document transactions, and this ticket and SERVER-40860 are known bugs. I'd like to confirm that drivers and mongos never send txnNumbers outside of retryable writes and multi-document transactions.

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