Summary

commitTransaction executed by withTransaction is not required to refresh timeoutMS (unlike abortTransaction, which is required to refresh timeoutMS). That is, a client does not do its best effort to make sure a transaction is terminated (either committed or aborted), unlike what it does for cursors. Instead, if a client decides to commit a transaction, but then discovers that the timeout is expired (or that it will likely expire due to the RTT before the client can get a response to commitTransaction), the client simply leaves the transaction unterminated on the server. Such an abandoned transaction blocks operations like dropping a collection/database (maybe some others) until it is terminated by the server based on the transactionLifetimeLimitSeconds.

Motivation

Who is the affected end user?

MongoDB users.

How does this affect the end user?

They cannot use the convenient transactions API without putting their applications at risk.

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

Quite likely.

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

Performance issues caused by abandoned transactions blocking other activities. I don't know whether having too many abandoned transactions slows down the server on its own.

Is this issue urgent?

We better address this specification bug sooner than later.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.

Acceptance Criteria

commitTransaction executed by withTransaction refreshes timeoutMS similarly to abortTransaction.

Note that the specification does not explain what "refresh" means exactly, and different engineers interpret it differently. It would have been great if the specification clarified that for all situations when it talks about refreshing timeoutMS.