fix(typescript): classify legacy PgQ errors

[NikolayS]

Summary

Fix the REV finding from #249: TypeScript classified only the modern PgQue error strings, while Go also recognizes legacy PgQ messages emitted by the SQL layer.

• map legacy queue errors to PgqueQueueNotFoundError:
  • no such queue
  • No such event queue
  • Event queue not created yet
  • event queue not found
• map legacy batch errors to PgqueBatchNotFoundError:
  • Cannot find data for batch ...
• add in-memory regression tests for all fragments so this parity hole stays shut

Test

• cd clients/typescript && bun run check && bun run test (30 passed, 50 skipped locally without PGQUE_TEST_DSN)
• git diff --check

[NikolayS]

REV — post-merge correction

This review should have been posted before merge. Process mistake: #251 was merged after local checks + CI, but without the REV artifact being written here first.

Scope: TypeScript client parity/code review only. SOC2/compliance checklist intentionally skipped.

Result

Clean after the #249 follow-up fix.

What was checked

• Error-classification parity against Go's classifyPgMessage() coverage:
  • queue not found
  • no such queue
  • No such event queue
  • Event queue not found
  • Event queue not created yet
  • batch not found
  • Cannot find data for batch ...
• SQL emitters verified in pgq/functions/* / sql/pgque-*:
  • pgq/functions/pgq.ticker.sql emits no such queue
  • pgq/functions/pgq.register_consumer.sql emits Event queue not created yet
  • pgq/functions/pgq.batch_event_tables.sql emits Cannot find data for batch %
• TS mapping now covers those fragments in clients/typescript/src/client.ts.
• Regression tests added in clients/typescript/test/client.test.ts using in-memory fake client errors, so DB availability is not required to keep this coverage.

Gates

• Local: cd clients/typescript && bun run check && bun run test → passed (30 passed, 50 skipped locally without PGQUE_TEST_DSN).
• CI before merge: all checks green, including TypeScript client tests.

Findings

No remaining blocker found in this follow-up. The previous REV blocker from #249 — TS missing legacy PgQ error strings — is fixed here.

[NikolayS]

REV rerun update — finding

Scope: TypeScript client parity/code review only. SOC2/compliance checklist skipped.

Finding

Medium — TypeScript still misclassifies mid-operation connection/pool failures as PgqueSqlError, not PgqueConnectionError.

Evidence:

• PgqueConnectionError documents mid-operation connection drops in clients/typescript/src/errors.ts.
• mapPgError() currently sends all unrecognized/non-Pg errors to PgqueSqlError in clients/typescript/src/client.ts.
• Go parity handles non-PgError operation failures as connection errors in clients/go/errors.go.

Impact: TS application recovery code cannot reliably catch PgqueConnectionError for closed-pool/network failures, unlike Go. Example path: client.close(); await client.send(...) can surface as PgqueSqlError.

Clean areas

• Queue/consumer/batch message mapping now matches Go/Python legacy PgQ fragments after fix(typescript): classify legacy PgQ errors #251.
• Consumer retryAfter is threaded into consumer-issued nack() calls and rejects negative/non-finite values.
• Docs are broadly truthful on retryAfter units and ack rowcount behavior.

Gates checked

• bun install --frozen-lockfile
• bun run check
• bun run test → 30 passed, 50 skipped locally without PGQUE_TEST_DSN
• fix(typescript): classify legacy PgQ errors #251 CI is green

Next action: open a follow-up fix PR for TS operation-time connection classification.