fix(clients/go): Nack placeholder, eager Connect ping, Consumer panic recovery

[NikolayS]

Closes #91.

Bugs fixed

Three regressions caught by red tests written in commit 672615b.

#	Bug	Fix commit
1	Nack() SQL had 11 placeholders ($2..$12) but pgque.message has 10 fields — pgx rejected the query with 42846	6d7b04a
2	Connect() called pgxpool.New (lazy) and returned nil error for unreachable hosts — failure only surfaced on the first query	bc4a2b9
3	Handler panic in Consumer.Start killed the poll goroutine and stalled the queue — subsequent messages were never delivered	0102caf

A fourth commit (7f2797d) improves test setup/teardown: lowers per-queue ticker thresholds, opens a fresh pool for cleanup to avoid use-after-close, and purges retry_queue/dead_letter rows before drop_queue.

Full go test output (local PG, all green)

=== RUN   TestSend
--- PASS: TestSend (0.05s)
=== RUN   TestSendAndReceive
--- PASS: TestSendAndReceive (0.03s)
=== RUN   TestNack
--- PASS: TestNack (0.03s)
=== RUN   TestNackPlaceholderCount
--- PASS: TestNackPlaceholderCount (0.02s)
=== RUN   TestConnect_UnreachableHostFailsImmediately
--- PASS: TestConnect_UnreachableHostFailsImmediately (0.00s)
=== RUN   TestConsumer_HandlerPanicRecoversAndContinues
2026/04/30 02:16:44 pgque: handler error for panic.test: handler panic: simulated handler panic
--- PASS: TestConsumer_HandlerPanicRecoversAndContinues (0.07s)
=== RUN   TestConsumerHandlerNacksOnError
2026/04/30 02:16:44 pgque: handler error for fail.test: simulated handler failure
--- PASS: TestConsumerHandlerNacksOnError (0.07s)
=== RUN   TestConsumerHandlerDispatch
2026/04/30 02:16:44 pgque: receive error: pgque: receive: closed pool
--- PASS: TestConsumerHandlerDispatch (0.02s)
PASS
ok  	github.com/NikolayS/pgque/clients/go	0.675s

Anti-leak confirmation

No internal GitLab, prospect, or benchmark work-item references in any changed file.

[NikolayS]

REV Review — PR #115

CI: green — claude-review pass, client-smoke pass, test (14/15/16/17/18) all pass, verify pass.

Functional evidence: Reviewed the post-fix files on fix/go-driver-bugs directly. Bug 1: pgque.message in sql/pgque.sql:4559-4570 has exactly 10 fields (msg_id, batch_id, type, payload, retry_count, created_at, extra1..extra4); the new Nack() SQL uses $1 for batch_id and $2..$11 for the 10 ROW fields, and the Go variadic passes 11 args in the matching order — placeholder/arg/field counts now line up. Bug 2: Connect() calls pool.Ping(ctx) before returning success and pool.Close()s on Ping failure, so unreachable hosts surface at call site without leaking a pool. Bug 3: dispatchWithRecover is invoked per-message (not once per goroutine) with a deferred recover() that converts the panic into a non-nil error; the existing error path in Start() then nacks the offending message and the loop continues. The three red tests assert the post-fix behavior (live Nack() succeeds, Connect() errors within 4 s on port 1, second handler call fires AND a retry_queue row appears for the panicking message). Live PG run was attached by the author in the PR body and shows all 8 tests green; I did not re-run locally.

Verdict: READY FOR USER REVIEW

Blocking

• None.

Non-blocking

• [LOW] [7/10] commit subject lengths — Several commits exceed CLAUDE.md's "Subject < 50 chars" rule: test(clients/go): red — three regressions for nack/connect/panic bugs (~69), fix(clients/go): consumer recovers from handler panics (~54), test(clients/go): improve setup/teardown robustness (~51). PR title is also ~79 chars. Fix: style nit only — not worth a re-spin; tighten on next round.
• [LOW] [6/10] clients/go/consumer.go Start docstring — The docstring on Consumer.Start was not updated to mention the new panic-recovery contract, even though Connect's and Nack's docstrings were. Fix: add one line like "Handler panics are recovered and treated as handler errors (the message is nacked, the loop continues)."

Potential

• [INFO] [5/10] clients/go/pgque_test.go Connect coverage — Only the unreachable-host case is exercised; no test for invalid-DSN syntax. Likely fine since pgx parses DSN inside pgxpool.New, which already returned a non-nil error pre-fix; the new code doesn't change that path. Worth a one-line test if you want belt-and-suspenders. Fix: optional — add TestConnect_InvalidDSN.
• [INFO] [4/10] clients/go/consumer.go:38-103 Start loop ack semantics — When a handler errors (or now, panics), the message is nacked but the loop still falls through to Ack(batchID) after processing all messages, which acks the batch even though one message was nacked. This is pre-existing behavior (not introduced by this PR — TestConsumerHandlerNacksOnError already covers it), and the docstring says "A batch is acked only if every handled message in it returned nil" which contradicts the implementation. Out of scope for this PR but worth a follow-up to either fix the doc or fix the code. Fix: track in a separate issue.
• [INFO] [4/10] dispatchWithRecover and runtime.Goexit — recover() does not catch runtime.Goexit(); if a handler ever calls t.FailNow or similar inside a goroutine that hits the dispatch path, the consumer goroutine still exits. Realistic? Almost never — production handlers shouldn't call Goexit. Documenting the contract ("panics are recovered; Goexit is not") would close the loop. Fix: optional doc-only.

Summary

Area	Findings	Potential	Filtered
Security	0	0	0
Bugs	0	1	0
Tests	0	1	0
Guidelines	1	0	0
Docs	1	1	0

Anti-leak: clean — no GitLab/internal/benchmark-WI references in diff, commits, title, or body.

---

REV-style review (security, bugs, tests, guidelines, docs). SOC2 items skipped per project policy.