Request for a further relaxing of the prepared transaction API. It would greatly simplify some parts of replication if prepared transactions could update selected tables after prepare and before commit. To maintain the underlying semantics of prepared transactions, any failures during this phase of the transaction would be fatal: the transaction cannot roll back so WiredTiger would have to panic instead.

There are a few motivations for this:

• it would allow MongoDB to avoid "side transactions" for writing the commit record to the oplog and updating the transaction table;
• it would avoid some situations where MongoDB has to allocate approximate timestamps prior to executing operations for real; and
• it would allow replication recovery to avoid re-applying operations (since recovery is not idempotent in some corner cases). Specifically, once we allow a transaction to commit with a commit timestamp earlier than the stable timestamp, recovery needs to know whether the transaction was applied in the checkpoint it is starting from. This very similar to the problem of retryable writes, but only works if the transaction table update is atomic with committing the original transaction.