Problem

With schema epochs, a new disaggregated table must stay in memory and write nothing to shared storage until it is published. WiredTiger decides whether a new table gets this treatment once, when the table is created, based on whether a stable schema epoch is set at that moment. A table created before the stable epoch is set is treated as a legacy table, can write to shared storage straight away, and is never re-evaluated.

WT-18176 made publishing panic when no stable schema epoch is set, which catches a caller that creates and publishes a table without ever setting the epoch. It does not catch a caller that creates a table, then sets the stable epoch, then publishes the table: the publish succeeds even though the table was never held back, so its data can reach shared storage before it is published. This is the ordering behind WT-18099 and WT-18112.

Proposed fix

When a table's creation is published, check the table itself, not only the global epoch: if it was created while no stable schema epoch was set, panic, as WT-18176 does.

The check must apply only to publishing a table's creation. Publishing a drop must not trigger it, because MongoDB also publishes drops, including drops of tables that may have been created before schema epochs were in use.

This is a targeted guard against bad API usage. The long-term fix, making the order of these calls irrelevant, stays with WT-18091.

Expected impact on MongoDB

None expected. Current MongoDB sets the stable schema epoch before it creates its catalog (SERVER-132361), creates the oplog after that, and publishes every table it creates in the same transaction that creates it.