Context
The new standby fast truncate design for disaggregated storage will perform truncate operations on the ingest table and add an entry into in-memory truncate list so that standby nodes never write directly to the stable table.
Problem
The new design will have slow truncate testing on the ingest table and a recording range entry in the truncate list, we need to validate that this behaviour is correct and add targeted tests that validate this workflow on follower. In particular, we have not systematically verified slow truncate on ingest tables and how inserts occur
txn_truncate:
- Performs the expected slow truncate on the ingest table for the requested key range.
- Inserts a matching truncate entry into the layered dhandle’s truncate list with the correct keys, timestamps, and transaction state.
This ticket closes that gap by validating and, if necessary, correcting the standby fast truncate API behaviour: adding focused unit and Python tests that exercise txn_truncate on followers and assert that (1) ingest-table contents reflect a slow truncate of the requested range, (2) the truncate list contains the expected entries.