The transaction API parses commitTransaction results specially to distinguish between command errors (ie top-level ok:0 errors), write concern errors (ie in the writeConcernError field), and client errors (e.g. errors sending the command itself or in client owned code, like the transaction callback), so it can choose to retry if either the command or write concern error is retryable.

SERVER-69194 added behavior so the API will rethrow any top-level error when running a command, and the API uses itself to run commitTransaction, so if a commit fails with a command error, it will now throw an exception with the command error, which makes the API treat it like a client error, preventing retrying on it. If commit fails with a command error and a write concern error, the exception will also swallow the write concern error, which prevents retrying on it as well.

The API should return the response from running a command unmodified, so the intended error handling logic can take effect.