Documentation Request Summary:

This adds a new set parameter called TransactionRecordMinimumLifetimeMinutes

I've dropped the comment that explains it in the code below

constexpr Minutes kTransactionRecordMinimumLifetime(30);

/**

• The minimum lifetime for a transaction record is how long it has to have lived on the server
• before we'll consider it for cleanup. This is effectively the window for how long it is
• permissible for a mongos to hang before we're willing to accept a failure of the retryable write
• subsystem.
  *
• Specifically, we imagine that a client connects to one mongos on a session and performs a
• retryable write. That mongos hangs. Then the client connects to a new mongos on the same
• session and successfully executes its write. After a day passes, the session will time out,
• cleaning up the retryable write. Then the original mongos wakes up, vivifies the session and
• executes the write (because all records of the session + transaction have been deleted).
  *
• So the write is performed twice, which is unavoidable without losing session vivification and/or
• requiring synchronized clocks all the way out to the client. In lieu of that we provide a weaker
• guarantee after the minimum transaction lifetime.
  */
  MONGO_EXPORT_STARTUP_SERVER_PARAMETER(TransactionRecordMinimumLifetimeMinutes,
  int,
  kTransactionRecordMinimumLifetime.count());

Engineering Ticket Description:

We need to provide a hook for transaction expiration which is invoked on all standalones and primaries to alert the retryable write subsystem when sessions have expired.

The lifetime and logic here seems identical to the rules for cursors (The cursor manager tells us what sessions are used by cursors, then we tell the cursor manager to drop the cursors attached to those sessions). We can replace the first step with a scan of the transaction table and the second with invocation of a callback that retryable writes can fill in (either via a callback injection or having them implement a service liason method).