-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Critical - P2
-
None
-
Affects Version/s: None
-
Component/s: Metadata, Schema Management
-
Storage Engines - Foundations
-
609.541
-
SE Foundations - 2026-08-18
-
5
Summary
On a disaggregated follower, a leader create -> drop -> create of the same layered table leaves the follower with a corrupt table handle. Reads of the recreated table fail with a bare WT_ERROR.
Hits a pure follower: one that only picks up checkpoints and never publishes its own schema operations, so pickup relies entirely on diffing shared against local metadata. This is the realistic replica topology.
Impact
Ordinary drop-and-recreate of a namespace poisons every pure follower:
- Best case: block manager catches the btree-ID mismatch and returns WT_ERROR; the recreated table is unreadable on the follower until it is rebuilt from scratch.
- Worse case: on a read path with looser validation, the follower serves the old table's data under the new table's name with no error, a silent correctness violation.
MongoDB drops and recreates namespaces routinely, so this affects data integrity on followers in the field.
Root cause
Two gaps in __disagg_apply_checkpoint_meta (src/conn/conn_layered_checkpoint_pick_up.c) combine on the same table name:
- Drop is a no-op on the follower (FIXME-WT-17746). The dropped table survives in local metadata with its original btree ID; the pickup drop branch is empty.
- Recreate reuses the stale entry (FIXME-WT-14730). Pickup copies the leader's new checkpoint address onto the stale entry but keeps the old id=, so the handle opens as the old btree while following the recreated btree's checkpoint.
Reproduction
Attached: test_layered_schema14.py. Asserts correct behavior, so it fails today and passes once the gaps are fixed.
Fix
Implementing the drop path (FIXME-WT-17746) is sufficient; the btree-ID conflict check (FIXME-WT-14730) is defense-in-depth.
- fixes
-
WT-17746 Handle table drop during checkpoint pick-up
-
- Open
-
-
WT-14730 Validate immutable metadata config fields on checkpoint pickup
-
- In Code Review
-
-
WT-17998 (Schema abort) Assertion failure: Unable to read root page error
-
- Closed
-
- is depended on by
-
WT-18284 Ensure correct handling of CREATE/DROP/CREATE patterns
-
- Needs Scheduling
-
-
WT-18232 failed: schema-disagg-abort-smoke-test-disagg-1 on amazon2023-disagg-stress [wiredtiger-disagg @ f85479d5]
-
- Closed
-
- is related to
-
WT-18099 (Leader) create/drop/create above stable schema epoch survives database recovery
-
- Closed
-
-
WT-18247 schema_disagg_abort aborts when checkpoint pick-up already applied a relayed drop
-
- Closed
-
-
WT-18293 Disagg database_size drop accounting is wrong when a dropped URI is recreated
-
- Needs Scheduling
-
-
WT-17746 Handle table drop during checkpoint pick-up
-
- Open
-
-
WT-14730 Validate immutable metadata config fields on checkpoint pickup
-
- In Code Review
-
-
WT-18150 Panic on btree ID conflict when picking up a new layered table
-
- Closed
-
- related to
-
WT-18101 Replaying table drop() on an already discarded table's data fails
-
- Open
-
-
WT-18099 (Leader) create/drop/create above stable schema epoch survives database recovery
-
- Closed
-
-
WT-18247 schema_disagg_abort aborts when checkpoint pick-up already applied a relayed drop
-
- Closed
-
-
WT-18293 Disagg database_size drop accounting is wrong when a dropped URI is recreated
-
- Needs Scheduling
-
-
WT-17091 Investigate and implement step-down for publish
-
- In Code Review
-
-
WT-18150 Panic on btree ID conflict when picking up a new layered table
-
- Closed
-
-
WT-18230 Disagg checkpoint can expose a recreated table before it is visible
-
- In Code Review
-
-
WT-18231 failed: schema-disagg-abort-smoke-test-disagg-1 on amazon2023-disagg-asan-stress [wiredtiger-disagg @ f85479d5]
-
- Closed
-
-
WT-18232 failed: schema-disagg-abort-smoke-test-disagg-1 on amazon2023-disagg-stress [wiredtiger-disagg @ f85479d5]
-
- Closed
-