Description

Description:

We are disallowing killCursors to be the first operation in a transaction

Engineering Ticket Description:

AsyncResultsMerger::blockingKill() sends a killCursors command to each of its remotes. However, it discards the callback handle for the request, so blockingKill() can return before the killCursors command reaches the remote. This means that if the client issues a killCursors command, and then a commitTransaction command, a shard can receive the commitTransaction before the killCursors. This is problematic in combination with transactions. Consider the following sequence of events:

• User starts transaction 0 with killCursors sent to mongos.
• User receives ok response.
• User sends commitTransaction for transaction 0 to mongos.
• mongod receives commitTransaction, which fails since transaction 0 does not yet exist.
• mongod receives killCursors, which starts transaction 0.

Now the mongod is stuck with transaction 0 open.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)