OPERATIONAL DEFECT DATABASE
...
...
BugZero found this defect 2612 days ago.
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.
ramon.fernandez commented on Thu, 14 Sep 2017 23:11:40 +0000: 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 schwerin commented on Fri, 25 Aug 2017 18:37:24 +0000: 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. jason.carey commented on Mon, 21 Aug 2017 18:06:12 +0000: 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)
./mongod ./mongo db.runCommand({insert: "foo", documents: [{x: 1}], txnNumber: NumberLong(1), lsid: {id: UUID("0123456789abcdef0123456789ABCDEF")}})
