Summary

In disaggregated storage mode, WT requires that no concurrent user-initiated operations run on layered tables during role transitions (follower→leader step-up or leader→follower step-down). This is part of the Role Transition Isolation contract: transitions actively modify layered table state — step-up drains ingest tables into stable storage, and step-down marks tables as read-only and stops writes. These operations are not safe to interleave with concurrent schema operations such as drop or create that access the same data handles.

During step-up, a concurrent drop can acquire the schema lock while drain is iterating over ingest table handles, leading to a use-after-free on the handle being drained. More broadly, any schema operation that races with state modification during a transition risks applying updates out of order, duplicating them, or skipping them entirely — all of which break the timestamp ordering invariants that layered storage depends on.

During step-down, schema operations that run after the node has relinquished leader status can trigger forced rollbacks or leave the storage layer in a partially-transitioned state, with potential for corruption.

There is currently no enforcement in WiredTiger that prevents schema operations from running during an active role transition. This makes the entire class of transition-concurrent schema bugs (e.g. BF-42866) silent to introduce and difficult to reproduce in testing.