Fast truncate has three implementations (attached storage, disagg leader, disagg follower) plus a step-up replay path and its behaviour is spread across cursors, transactions, the truncate list, checkpoint pickup and reconciliation. The design documents describe intent, not what was built; WT-17272, WT-17637 and WT-17775 all came from gaps between the two. There is no single reference to read before touching or reviewing truncate code.

Goal:

An architecture document describing the implementation as it exists in develop, its divergences from the design documents and the known gaps.

Scope:

Per mode, the call path from WT_SESSION::truncate down and the state it produces:

1. Attached storage: range resolution (__wt_session_range_truncate), fast page delete (WT_REF_DELETED, __wt_delete_page) versus slow per-key path (__wt_cursor_truncate), instantiation on read, logging.
2. Disagg leader: reuse of the attached-storage path on the stable table; propagation to followers via checkpoints.
3. Disagg follower: in-memory truncate list (WT_TRUNCATE_LIST), ingest tombstones, entry commit/rollback, GC on checkpoint pickup, debug.disagg_slow_truncate_follower fallback.
4. Step-up: multi-pass ingest drain interleaved with truncate-list replay (__layered_drain_ingest_table_and_truncate_list).

Interactions:

• Cursors: search, search_near, next/prev, random, bounds; which consult __wt_truncate_delete_visible_check and which skip deleted pages.
• Transactions and visibility: commit/durable timestamps on list entries, read timestamps, prepared transactions (unsupported for follower truncate), autocommit.
• Write conflicts: truncate vs write, truncate vs truncate; checks in __clayered_put / remove and __clayered_truncate_follower; the check-then-insert window.
• Reconciliation and eviction: page-delete handling, instantiation, tombstone-on-tombstone invariant in __rec_append_orig_value.
• Checkpoint, recovery, RTS and history store where truncate state is involved.
• Statistics, verbose categories, debug knobs.