fix(audit): track deleteHistory removals with bounded concurrency

[kriszyp]

What

Table.deleteHistory() — the LMDB path behind delete_transaction_logs_before — overwrote each iteration's removal promise and awaited only the last one. A non-final rejection therefore surfaced later as an unhandled rejection.

The fix now tracks every audit-entry or tombstone removal immediately, attaches failure handling at creation, permits at most 10 removals in flight, and drains each phase before returning. This keeps storage writes overlapped without restoring the original unbounded pending set.

removeAuditEntry() also joins the delete callback that removes the corresponding primary-store tombstone, instead of firing that promise and forgetting it.

Why

Under Bun, an unhandled rejection here killed Harper a few seconds after the cleanup job had already reported COMPLETE. The delayed failure looked like a native storage crash, but the root cause was detached JavaScript promises in the prune loop.

This mirrors the fix already merged for the sibling scheduleAuditCleanup loop in #1963.

Changes

• resources/Table.ts
  • Tracks every deleteHistory() removal in a local set.
  • Applies backpressure at 10 in-flight removals and drains before the optional tombstone sweep and before return.
  • Counts only successful audit removals.
  • Keeps tracked promises fulfilled even if failure logging itself throws.
  • Returns the primaryStore.remove(id, version) promise from the delete callback.
• resources/auditStore.ts
  • Joins tombstone removal with audit-store removal.
  • Contains both synchronous callback throws and asynchronous rejections, while logging tombstone cleanup failures separately.
• unitTests/resources/auditLog.test.js
  • Covers a mid-loop rejection, success-only counting, continued pruning, warning attribution, and a throwing warning handler.
  • Proves exactly 10 removals can run concurrently, the eleventh waits, and all 11 complete.
  • Covers rejecting and synchronously throwing delete callbacks.
• DESIGN.md
  • Records the promise-tracking and tombstone-callback invariants.

Verification

• npm run build — passed.
• HARPER_STORAGE_ENGINE=lmdb npx mocha unitTests/resources/auditLog.test.js — 21 passing, 5 pending.
• npm run test:unit:resources — 1,354 passing, 17 pending.
• HARPER_STORAGE_ENGINE=lmdb npm run test:unit:resources — 1,202 passing, 79 pending.
• npm run test:unit:main — 4,211 passing; 10 pre-existing globalIsolation.test.js failures caused by this nested worktree resolving mqtt through the parent checkout.
• npx harper-integration-test-run integrationTests/apiTests/transaction-logs.test.mjs with an isolated loopback pool — 7/7 passing.
• npm run test:integration:all with an isolated loopback pool — current-version suites completed cleanly; two legacy 5.1 cross-version suites failed before their test bodies because the nested worktree's generated Unix-domain socket path exceeded the kernel limit (listen EINVAL).
• The concurrency test was verified to fail under the prior sequential cap and pass at 10.
• The throwing-logger regression test was verified to fail without the terminal catch and pass with it.
• Pre-push review at the pushed head: Claude + Gemini delta review, carrying forward a full Claude + Gemini + Harper-domain review of the complete PR diff.

Risks & open questions

• deleteHistory still cannot report partial or total removal failures through DeleteTransactionLogsBeforeResults. A systemic failure can return entries_deleted: 0 with a successful operation response and may emit one warning per failed record. Changing the result schema or abort policy is a separate design decision.
• The real addDeleteRemoval callback wiring is covered indirectly. Dropping the callback's new return specifically would not fail the current tests.
• Both deleteHistory regression tests are LMDB-only, matching the code path, and the optional cleanupDeletedRecords phase does not have dedicated concurrency coverage.
• Joining tombstone removal makes the automatic background cleanup wait for that primary-store write. This is correct but can reduce delete-heavy cleanup throughput.
• A failed automatic tombstone removal is logged, but the audit entry is still retired; automatic cleanup therefore loses its retry trigger and requires an explicit cleanup_deleted_records: true sweep later.

Refs #1963

Co-Authored-By: GPT-5 Codex noreply@openai.com

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request addresses a promise handling issue where audit-entry and tombstone removal loops did not properly await each iteration's promise, leading to unhandled rejections and missed cleanups. The changes ensure that each removal is awaited inline and errors are caught and logged. Additionally, regression tests were added to verify this behavior. The reviewer suggested simplifying the promise wrapping in removeAuditEntry by using new Promise to catch both synchronous throws and asynchronous rejections in a single block, eliminating the redundant try/catch block.

[claude]

Reviewed; no blockers found.