Summary
Investigate how prepared transactions can be supported in async step-down (the step_down_timestamp mechanism on disaggregated storage). Prepared transactions were excluded from the core implementation (WT-17895) and are out of scope for the public preview. This ticket identifies the gap and the mechanism options; a follow-up ticket will implement the chosen approach.

Problem
Async step-down resolves straddler transactions (begun before the step-down timestamp is set, committing after it) with a detect-and-rollback strategy: commit returns WT_ROLLBACK and the application retries into the ingest table. A prepared transaction cannot be rolled back, so this strategy does not work for it. Example:

session->begin_transaction()
Perform updates.
Acquire the oplog mutex and obtain a prepare timestamp.
session->prepare_transaction("prepare_timestamp=10")
Acquire the oplog mutex and set stepdownTs = 11.
Acquire the oplog mutex again and obtain a durable timestamp.
session->commit_transaction("durable_timestamp=12")

This straddler is prepared before stepdownTs but commits after it. Its updates already reside in the stable tree (whereas they should have been on ingest), but its commit timestamp (12) is greater than stepdownTs (11), so it can be neither rolled back nor safely committed.

Current behavior and scope of investigation

• The code blocks this case with assertions that abort the process (__wt_txn_prepare in src/txn/txn.c and __session_commit_transaction in src/session/session_api.c). The prepare-time check does not catch the sequence above, so the commit-time check fires and fails the system.
• Prepared transactions need a different mechanism than detect-and-rollback. Evaluate the possible directions: blocking prepare while a step-down is pending, moving the prepared updates to the ingest table at commit, or committing at or below the step-down timestamp.