Aptos Core maintainers have merged a critical bug fix that resolves state KV truncation leaks in the database pruning system. The issue, documented in PR #352, occurred when the `truncate_state_kv_db_shards` function failed to discover and delete orphaned state values for first-time key creations.
The root cause lay in the truncation logic's reliance on `StaleStateValueIndexByKeyHashSchema` to identify entries for deletion. However, first-time key creations—where no previous version existed—never wrote a stale index entry, causing the truncation scan to miss them entirely. This left orphaned `StateValueByKeyHashSchema` entries beyond the truncation point, potentially leading to database bloat and performance degradation.
The fix introduces a sentinel stale index entry with `version = Version::MAX` for first-time key creations. This allows the existing `stale_since_version`-based scan to discover these entries and clean them up properly. The pruner skips unnecessary no-op deletes by checking `is_first_write()` against the sentinel, ensuring efficiency.
Test coverage was extended significantly: the test suite in `db_debugger/truncate/mod.rs` now uses an account pool of 500 (up from 5) to reliably trigger new key creations past the truncation target version, and proptest cases increased from 1 to 5. A new parameterized helper, `arb_blocks_to_commit_with_params`, was extracted to improve test flexibility. Existing pruner and state store tests continue to pass, confirming backward compatibility.