Background

On a follower, a range truncate on a layered table is recorded twice: as an entry in the truncate list, which is replayed against stable at step-up, and as per-key tombstones in the ingest table, so the follower's own reads see the deleted range. The step-up drain cannot tell those tombstones apart from tombstones written by explicit removes. When an update or remove commits at the same timestamp as a truncate over the same key, the drain can copy the ingest tombstone and then replay the truncate on top of it. A same-timestamp write that should survive the truncate is then buried, and the stable update chain can end up with stacked same-timestamp tombstones.

WT-17427 tracks the proper fix of telling the two kinds of tombstone apart. Until that lands, this ticket closes the hole by rejecting the workloads that can produce the ambiguity.

Proposal

Add two restrictions for follower range truncates on layered tables.

1. No other operations in a truncating transaction. A transaction that performs a follower range truncate may contain only that truncate and the per-key ingest tombstones it generates. If the transaction also contains an unrelated insert, update, modify, or remove, commit and prepare return WT_ROLLBACK and the whole transaction rolls back.
2. No shared commit timestamp with a truncate. A write to a layered table must not commit at the same timestamp as a follower truncate whose range covers its key, and a truncate must not commit at the timestamp of an existing ingest write inside its range. The later of the two to commit fails with an error.

Both restrictions are short-term. They should be lifted once the drain can distinguish truncate-generated tombstones from explicit removes.