fix(test): de-flake auditLog 'check log after writes and prune'

[kriszyp]

What

De-flakes the Audit log > check log after writes and prune unit test (unitTests/resources/auditLog.test.js), which was intermittently failing on main's Unit Test workflow (Node 22 leg) with AssertionError: Should have at least a couple of update events.

Why it was flaky (root cause, not just symptoms)

Investigated the write→subscription-event path (resources/transactionBroadcast.ts, resources/Table.ts) before touching the test, per the task's instruction to rule out a real product bug first.

Table.ts's per-key subscription listener intentionally forwards only the latest value for a given id: if the current primary-store entry's version no longer matches the audit record being processed, the record is dropped as "out of order" (an accepted design choice — confirmed by a prior commit, "It is possible that not every write will result in an event", which is what relaxed this assertion from === 4 to > 2 in the first place). Delivery itself is asynchronous: a 'committed' event is coalesced and deferred via setImmediate before the audit log is walked and subscribers notified.

The test's write sequence only touched two distinct ids:

• id 1: put → delete
• id 2: put → put (changed)

Given the coalescing rule above, the guaranteed floor of delivered events for this sequence is exactly 2 (the final write to each id) — not 3. Getting a 3rd event depended on the async notify pass happening to run between two same-id writes, which is inherently timing-dependent and explains the correlation with loaded/degraded CI runners in issue #1939.

This is not a product bug: the coalescing behavior is intentional and was already accepted product behavior. It is a test that asserted a floor the design doesn't actually guarantee.

Fix

• Added a third id (99) with a single write that is never superseded within the test, guaranteeing (regardless of scheduling) that its event survives coalescing — making the "at least 3 events" floor deterministic instead of a timing gamble.
• Per independent review feedback (see below), replaced the raw events.length >= 3 count check with content-based assertions for the three specific terminal events (put(99), put(2, two-changed), delete(1)), using the shared unitTests/waitFor.js condition-wait helper. A bare count could otherwise be satisfied by early, coalescible events without ever proving the terminal writes were delivered.
• No production code changes.

Testing

• npm run build (TypeScript build, clean)
• unitTests/resources/auditLog.test.js (targeted test): 20/20 passing locally (idle), 12/12 passing under artificial full-core CPU load (nproc busy-loop processes), 10/10 passing under HARPER_STORAGE_ENGINE=lmdb (exercises the prune branch this test also covers)
• Full unitTests/resources/auditLog.test.js suite: 19/19 passing
• Full npm run test:unit:resources: 1286 passing, 14 pending, 0 failing (matches the clean-run baseline noted in the dispatch)
• Independent pre-push review (Codex, outside-model leg): first pass raised one finding (count-only assertion doesn't prove which events arrived); addressed by switching to content-based assertions. Second pass: verdict: LGTM, no findings.

Out of scope

The same workflow's Node 24/26 legs fail on an unrelated rocksdb-js Invalid column family specified in write batch error (issue #1381) — not touched here.

Refs #1939

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request refactors the audit log unit test to address flakiness under CI load. It replaces a fragile fixed-delay polling loop with a robust waitFor utility that asserts on specific terminal events by content rather than just checking the event count. Additionally, a non-superseded write (ID 99) is introduced to ensure its event survives coalescing. I have no feedback to provide as the changes are well-implemented and follow the repository's testing practices.

[claude]

Reviewed; no blockers found.