fix(ts): back off on nack/ack failure in consumer

[NikolayS]

Bug

Consumer.start() in clients/typescript/src/consumer.ts slept pollIntervalMs only on receive error or empty batch. When a batch was received but finalization failed — a nack failed so ack was intentionally skipped, or ack() threw — the while loop re-polled immediately. Because the batch was never finished, pgque.next_batch returns the same batch instantly, so:

• a persistent nack/ack failure (e.g. partial grants where receive works but nack/ack don't) becomes a tight loop at full speed: re-receive → re-run ALL handlers (duplicate side effects) → fail → repeat, hammering both the application and Postgres;
• even a single transient ack failure re-executes the whole batch's handlers with zero delay.

The comment on the skip-ack path even claimed redelivery happens "on the next poll" — a poll interval that did not exist on that path.

Fix

await sleep(this.pollIntervalMs, signal) before re-polling on both the anyNackFailed path and the ack-throw path. The existing sleep helper is abort-aware, so shutdown latency is unchanged. ack returning 0 without throwing stays warning-only with no sleep (the batch is finished in that case; the loop should keep draining).

Red/green TDD: two new mock-based tests (pollInterval: 60_000, receive always returns the same batch, nack/ack fail persistently) assert receive is called exactly once within a 300 ms observation window. Unfixed, the hot loop is so tight that the vitest worker dies of OOM recording mock calls — that was the red run. Green after the fix.

Second commit (informational note from the same review): src/producer_bench.ts spliced the table name from pgque.current_event_table() into select count(*) from ${table} via a template literal — not exploitable (self-generated value, dev-only script) but the only non-parameterized query in the repo. Now quoted part by part with pg's escapeIdentifier. Also fixed the result generic: the pgque pool parses int8 (OID 20) to BigInt, so count(*) arrives as bigint, not string; the old <{ count: string }> + Number.parseInt only worked by coercion.

Verification

All run in clients/typescript/ (deps via bun install):

bun run check
# tsc --noEmit -p tsconfig.json && tsc --noEmit -p tsconfig.test.json — clean

npx vitest run    # without PGQUE_TEST_DSN
# Test Files  7 passed | 1 skipped (8)
#      Tests  35 passed | 50 skipped (85)

# Integration: fresh scratch DB on local PG 16, pgque installed via \i sql/pgque.sql
PGQUE_TEST_DSN="postgres://root:***@localhost:5432/pgque_ts_b1_oqxpbr" npx vitest run
# Test Files  8 passed (8)
#      Tests  85 passed (85)

# Bench script live run (exercises the quoted-identifier path; verifyCount passes):
PGQUE_TEST_DSN=... PGQUE_BENCH_REPEATS=1 bun src/producer_bench.ts
# table + CSV output produced, no verification errors

Red run (before the fix, same test file): the consumer.test.ts worker crashed with FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory — direct evidence of the unbounded hot loop.

Addresses finding B1 (TypeScript) and the producer_bench informational note of #283

https://claude.ai/code/session_01KAaEGkQZmey1D1xCsVGmqv

---

Generated by Claude Code