fix: experimental SQL bugs + CI coverage#288
Conversation
samorev Code Review Report
BLOCKING ISSUES (1)HIGH
Summary
Note:
Review metadatasamorev-assisted review (AI analysis by Tanya301/samorev) |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
bf597d1 to
1183a84
Compare
Deep review + real testing (relocated onto stable/devel split)Rebased onto current Review findings
Correctness — A1 ( Correctness — A2 (negative Correctness — D2 (CI coverage): the new SECURITY DEFINER / search_path: Real testing (fresh Docker Postgres 16)Pre-fix code (main's After the fixes: Full experimental suite ( Default suite unaffected: CI on head Verdict: MERGE-READY. |
samorev Code Review Report
No blocking issues. One non-blocking nit below; the fixes are correct and now CI-gated. What was verified
NON-BLOCKING (1)INFO
Notes (not findings): the carried-over 2-line Summary
Note:
Review metadatasamorev-assisted review (AI analysis by Tanya301/samorev) |
Bugs
A1 (medium) —
pgque.throughput()division by zero for sub-minute buckets.sql/experimental/observability.sqlaligned buckets with% (extract(epoch from i_bucket_size)::int / 60). Integer division makes the divisor 0 for any bucket size under 60 seconds, soselect * from pgque.throughput('q', '1 hour', '30 seconds')aborted withdivision by zerowhenever ticks existed in the window. Sizes between 60 s and 120 s that are not minute multiples (e.g.'90 seconds'→% 1) silently collapsed to minute boundaries.A2 (low) —
pgque.create_queue(text, jsonb)accepted negativemax_retries.sql/experimental/config_api.sqlspecial-cased'max_retries'with a directupdate pgque.queue, bypassing the>= 0validation inpgque.set_queue_config(). With'{"max_retries": -1}', thecoalesce(ev_retry,0) >= v_max_retriescheck inpgque.nack()is always true, so every event dead-letters on first nack. History check: the special case landed in the same commit (8a54a7e) that introduced the validatingset_queue_config()override, which already acceptsmax_retries— the special case was redundant, never a workaround.D2 (low) — experimental SQL had zero CI coverage.
tests/run_experimental.sqlwas referenced by no workflow, which is exactly how A1/A2 shipped.Fixes
to_timestamp(floor(extract(epoch from tick_time) / extract(epoch from i_bucket_size)) * ...)— so any positive interval works; rejecti_bucket_size <= interval '0'(or null) with a clear exception.pgque.set_queue_config(), dropping the special case, so negative values are rejected with the canonical error (max_retries must be >= 0).Run experimental testsstep in thetestjob of.github/workflows/ci.yml(full PG 14–18 matrix): installssql/pgque.sqlplus the threesql/experimental/*.sqlfiles into a separatepgque_experimentaldatabase (so the later idempotency/uninstall steps keep testing the default install) and runstests/run_experimental.sql.Red/green TDD: tests added first and confirmed failing, then the fixes. New tests:
tests/test_observability.sql: throughput with'30 seconds'bucket (was: division by zero), exact 90-second bucketing with synthetic ticks (2 buckets, 100/150 events), non-positive bucket size raises.tests/test_experimental_config_api.sql:create_queue('q', '{"max_retries": -1}')raises the canonical error and the queue is not created.Verification
Fresh scratch DB, PostgreSQL 16:
Result (tail):
Pre-fix run of the same suite failed with
ERROR: division by zero(test 9) andERROR: create_queue should reject negative max_retries(config test), confirming red before green.Main suite unaffected — fresh DB:
Result:
=== ALL TESTS PASSED ===(exit 0).sql/experimental/*.sqlis not embedded in the generatedsql/pgque.sql(verified: nothroughput/jsonbcreate_queuein it), so no rebuild viabuild/transform.shwas needed.Addresses findings A1, A2, D2 of #283
https://claude.ai/code/session_01KAaEGkQZmey1D1xCsVGmqv
Generated by Claude Code