A driver puts `lsid` on every acknowledged command already, because
`add_server_info` advertises `logicalSessionTimeoutMinutes`. So this is not new
plumbing, it is a decision about input that has been arriving all along and
being ignored. Accepting it and doing nothing is honest: a session here would
own nothing -- no transactions to scope, no retryable writes, cursors that
outlive their connection for their own reasons. There is deliberately no
session registry; it would be a mutex on the dispatch path guarding state
nothing reads, and M4's transaction state machine is what should decide its
shape.
`txnNumber` is a different matter, and ignoring it would be the lie this
commit exists to remove. A transactional write would run non-transactionally,
answer `ok`, and become durable; the client would find out at
`commitTransaction`, by which time the data is on disk. It is refused, with
`startTransaction` and `autocommit` alongside it for the same reason.
Every code and every message was measured against mongod 8.3.7 through a raw
OP_MSG probe -- the driver overwrites `lsid` with its own session, so a
malformed one cannot be sent through it and none of this was checkable the
usual way. Three things the measurement settled that guessing would have got
wrong: an unknown command with a malformed lsid answers CommandNotFound, so
the lookup comes first and this check belongs exactly where it sits; the codes
for a bad session id are IDL parser codes (40414, 40415) rather than anything
resembling the rest of our table; and a bad UUID length is InvalidUUID 207
while a bad subtype is TypeMismatch 14, which no amount of reasoning would
have produced.
Three divergences from mongod, all one cause: it keeps a per-command table of
which commands accept `txnNumber` at all, and answers Location50889 or
OperationNotSupportedInTransaction 263 for those that do not, before reaching
the standalone refusal. We have no such table and give the standalone answer
uniformly. For every CRUD command -- everything a driver would actually send
these fields on -- the replies are identical; they differ only on things like
`ping`, where mongod is more specific rather than differently right.
Checked before any lock is taken, and the test for that is the second half of
each refusal: keep using the engine afterwards, with a write that has to take
the catalog exclusive to create a collection. Mutation-checked by moving the
call below `lock_catalog` -- the test run hangs, which is precisely how the
nameless-command lock leak presented, since a leaked *shared* lock is
invisible to every reader.
174/174 unit tests.
54092f44be