The application turns disaggregated schema epochs off by no longer setting the stable schema epoch. WiredTiger does not update the stable schema epoch when it installs a checkpoint, so this takes effect when a node restarts, and until now that node's checkpoints recorded no epoch at all.

An epoch of zero means the legacy world to every reader, which causes two problems. A node still using the feature that picks up such a checkpoint discards its entire shared metadata queue, losing its unpublished schema operations. And the epoch the database had reached is erased from shared storage, so a later era can hand out epochs that were already used.

Change

A checkpoint now records the higher of the live stable schema epoch and the epoch already in shared storage, so the value is carried through the period with the feature off.

The epoch that gates behaviour is deliberately left alone. Deferral, publishing, the epochs stamped on queued metadata operations, and the choice between legacy and epoch-aware recovery all continue to follow the live stable schema epoch. A node that is not gating schema operations therefore still behaves as a legacy node, while its checkpoints stay readable by a node that is still using the feature.

Because the epoch now survives the gap, it can also serve as a floor:

• a leader may not set a stable schema epoch below the one recorded in the last checkpoint;
• a checkpoint may never record an epoch older than the one already in shared storage.

The floor applies to leaders only, and rejects strictly lower values rather than equal ones, because a follower legitimately runs with a stable schema epoch at or below the epoch in the checkpoint it picked up.

Testing

New test_layered_schema28.py covers running without the feature on a database that used to have it: schema operations during the off period, role transitions including the window between an off restart and the node's first checkpoint, a node still using the feature reading an off node's checkpoint, the return to epochs, and the rejection of an epoch below the recorded one.

Notes

Distinguishing a deliberate off from an oversight, where the server meant to set the epoch and did not, is not addressed here and needs its own ticket.