-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Truncate
-
Storage Engines - Foundations
-
SE Foundations - 2026-04-10
-
5
A POC branch now implements fast truncate for primary nodes in disaggregated mode by wiring layered truncates to the ASC fast truncate path on the stable table. However, this behaviour has not yet been validated against the fast truncate design or existing ASC semantics, and all fast truncate Python tests are currently disabled or failing against the POC branch.
As a result, we do not yet know whether:
- Layered truncates on primaries preserve the required visibility, write‑conflict, and replay semantics defined in the fast truncate design.
- Layered cursors always issue fast truncate to the stable table, or still fall back to slow truncate in some code paths.
- The POC maintains the performance and availability goals that motivated fast truncate for change streams and oplog truncation, without introducing correctness regressions.
This ticket addresses that gap by validating the primary fast truncate POC for layered tables: reviewing the implementation against the design, confirming that layered truncates use the intended fast truncate semantics, and re‑enabling/triaging all fast truncate tests for primary/disagg so regressions are caught in CI.