Background

WT_CONNECTION::set_timestamp(step_down_timestamp=...) marks the step-down boundary in timestamp space only. A layered schema operation issued after the step-down timestamp is set is treated as belonging to the next leader era, so a create in that window skips its stable constituent.

Schema epochs are a separate ordering space, and nothing ties the two together. WT_SESSION::publish accepts any epoch above the stable epoch regardless of the step-down timestamp, so a client can publish an operation at an epoch that logically lands on the wrong side of the step-down boundary. WiredTiger cannot detect this today and relies on the client getting it right.

No reliable way to identify a window create

Because the boundary does not exist in epoch space, code that needs to recognise a create made inside the step-down window has to infer it. The only available signal is a queued CREATE whose stable_value is NULL, meaning the create captured no stable constituent. That signal is not sufficient.

With schema epochs, an unpublished create keeps the WT_SCHEMA_EPOCH_UNPUBLISHED sentinel, so the epoch check in __wt_disagg_shared_metadata_queue_process defers it indefinitely and it is still queued at step-down carrying the constituent it built. An ordinary create and a window create are therefore indistinguishable by anything except the missing constituent, and the missing constituent does not uniquely mean "window create".

The consequence today is that __layered_assert_step_down_created can only run in legacy mode, where the demotion checkpoint drains every ordinary create so a still-queued create must be a window create. Under schema epochs the assertion is skipped entirely and the invariant goes unchecked.

Proposal

Have the client supply a step-down epoch together with the step-down timestamp, so the boundary is expressed in both spaces and can be enforced. With it we can:

• Reject a publish whose epoch falls on the wrong side of the boundary.
• Assert the published and stable epochs against the step-down epoch at step-down, the same way we already assert the stable timestamp.
• Replace the ad-hoc "is a step-down timestamp set" test that currently gates leftover parked creates in __wt_disagg_shared_metadata_queue_process with a real epoch comparison.
• Identify a window create from its epoch rather than from a missing stable constituent, so __layered_assert_step_down_created can cover both modes.

This is an API change and needs coordination with the client.