Retryable sessions used for retryable transactions have special rules for when they can be reaped from the SessionCatalog. Each session is tied to a txnNumber for some client session and can be reaped once a transaction or retryable write with a higher txnNumber has started on that client session. To remove retryable sessions as soon as possible, they are erased from the SessionCatalog after a new transaction/retryable write starts on a mongos or mongod and the session of the new write is released.

This logic does not currently work when a mongod accesses the same retryable session from the router and participant roles (ie TransactionRouter and TransactionParticipant). The participant keeps a map of retryable sessions for the latest transaction, so if the router role tries to clear a retryable session, it may still be in the map, and if the same process accesses that session in the participant role, it may use the freed session and crash. There are very few remote transactions run from a mongod currently, so early reaping was disabled in the router role on a mongod (in SERVER-75919), but we should enable the reaping safely.