Summary

When a follower is promoted to leader (step-up), prepared updates that were previously claimed on the follower but do not have a transaction id assigned should be reclaimed into the new leader's transaction state instead of being dropped. Today these claimed prepared transactions are lost across step-up because the claim is conditioned on the presence of a txn id.

Motivation

On the follower, prepared updates can be claimed without ever being assigned a transaction id (the follower is replaying / observing prepared state rather than originating it). When the node steps up to leader, the claim must persist so the new leader can subsequently commit or roll back the prepared transaction. If the claim is dropped, the prepared update is left in-memory with no owning transaction, which prevents resolution and can manifest downstream as prepare-conflict timeouts (see WT-17304) or assertion failures during reconciliation/RTS.

Acceptance Criteria

• A claimed prepared update with no transaction id on the follower is preserved across step-up and re-attached to a transaction on the new leader
• After step-up, the reclaimed prepared transaction can be committed or rolled back through the normal API
• Existing preserve_prepared / prepare-claim tests pass with no regression
• A test covering the follower → leader step-up path for a claimed-but-no-txn-id prepared update is added

Related

• WT-16600 — Investigate how to allow a prepared transaction survive step-up in disagg (initial step-up survival work; this ticket extends it to claimed-no-txn-id case)
• WT-17275 — Support prepare claim for fast truncate to reconstruct prepared transactions on restart
• WT-15967 — Create the prepared update on the ingest table in standby when claiming the prepared update