[SERVER-30765] Don't allow txnNumbers in commands for standalone mongods Created: 21/Aug/17  Updated: 30/Oct/23  Resolved: 14/Sep/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.11
Fix Version/s: 3.6.0-rc0

Type: Bug Priority: Major - P3
Reporter: Jack Mulrow Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-30540 Throw an error if retryable writes is... Closed
Related
related to SERVER-69517 moveChunk command fails with "Transac... Closed
related to SERVER-41531 Support transactions on standalone in... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

./mongod
./mongo
db.runCommand({insert: "foo", documents: [{x: 1}], txnNumber: NumberLong(1), lsid: {id: UUID("0123456789abcdef0123456789ABCDEF")}})

Sprint: Sharding 2017-10-02
Participants:
Linked BF Score: 0

 Description   

If a standalone mongod receives a write command with a valid txn number and logical session id, it will assign a statement id to each write, but because isOplogDisabledFor will always return false, since replication is not enabled, this invariant will be hit here.

I'm not completely sure the invariant even needs to stay, since statement ids are only used after this check for inserting to the oplog, but regardless, since retryable writes aren't supported on standalone mongods, a command with a txn number should return a bad status instead of crashing the node.



 Comments   
Comment by Ramon Fernandez Marina [ 14/Sep/17 ]

Author:

{'username': u'jsmulrow', 'name': u'Jack Mulrow', 'email': u'jack.mulrow@mongodb.com'}

Message:SERVER-30765 Only allow transaction numbers on mongos or replica set members
Branch:master
https://github.com/mongodb/mongo/commit/8f4b4d65a83777e3ab18bdaa8c17717d3d066b2e

Comment by Andy Schwerin [ 25/Aug/17 ]

I think that mongorestore needs applyOps to work with oplog entries that have txnNums even when the restore target is a standalone node. Otherwise, this seems OK.

Comment by Mira Carey [ 21/Aug/17 ]

I wonder if it's worthwhile adding a top level feature object to check against in initializeOperationSessionInfo (that's the function which scoops the txn and lsid out of the command pre-dispatch in mongod/mongos).

We already do a check there for requiresAuth (sessions and retryable writes are disabled for non-auth'd commands)

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