Summary

In the sequence of actions section of the convenient transactions API (see step 9), we never run abortTransaction when commitTransaction fails. This may be because a failed commit may unpin the session and the abort may run on a different mongos in sharded clusters. If commitTransaction times out (either due to default withTransaction timeout or a CSOT timeout), the transaction will not be committed and will not be aborted. This means no new transaction can be started on the session and other transactions on other sessions may encounter write conflicts. Should we reconsider running abortTransaction if commitTransaction fails with a non-retryable error in withTransaction?

Motivation

Who is the affected end user?

Users of the convenient transactions API (particularly when using timeouts).

How does this affect the end user?

Potential write conflicts and unexpected session errors.

How likely is it that this problem or use case will occur?

A little unlikely. For the case of timeouts, the timeout would have to occur after the callback's operations but before commitTransaction finishes.

If the problem does occur, what are the consequences and how severe are they?

Potential write conflicts and unexpected session errors.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

mongosync brought up this issue in the Go driver (see related issue).

Is this ticket only for tests?

No.