-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Reconciliation
-
None
-
Storage Engines - Transactions
-
4.32
-
SE Transactions - 2026-07-03
-
5
Context & The Production Crash We recently investigated a production crash (AF-17117 ticket) caused by a step-up assertion failure. The root cause was a race condition between concurrent truncate operations that resulted in non-globally visible tombstones.
The Primary Fix This crash is already being addressed in WT-17674 by making truncate non-transactional. This change will ensure that tombstones are immediately globally visible, effectively preventing the assertion failure.
The Anomaly (Why this ticket exists) While the non-transactional truncate will fix the production crash, we discovered a strange anomaly during the investigation that is still worth looking into: the update chain was entirely empty except for a single delete from the truncate. There should have been prior globally visible updates in that chain. If those expected updates had actually been present, the original race condition would have simply triggered a restore page eviction (a minor performance hit) instead of taking down the server.
Action Items Even with the primary WT ticket fix in place, we need to investigate this anomalous behavior:
- Determine why prior globally visible updates are missing from the reconciliation chain when a single truncate delete is present.
- Trace the logic to ensure there isn't a deeper bug causing update chains to silently drop data under these conditions.
- related to
-
WT-17674 No-timestamp tombstones in ingest btree causing assertion failure
-
- Investigating
-