Skip to content

test: install the pg-boss schema the HTTP suite reads - #1

Merged
ethanasm merged 1 commit into
mainfrom
claude/main-branch-fix-zeo639
Aug 7, 2026
Merged

ethanasm merged 1 commit into
mainfrom
claude/main-branch-fix-zeo639

Conversation

@ethanasm

@ethanasm ethanasm commented Aug 7, 2026

Copy link
Copy Markdown
Owner

Fixes the red Integration job on main (run 31145237749).

What was failing

UnsupportedSchemaError: Schema "pgboss" is empty or not visible to this role.
 ❯ PgBossAdapter.#refs src/pgboss/adapter.ts:76:39
 ❯ PgBossAdapter.queueOverview src/pgboss/adapter.ts:133:18
 ❯ collectSnapshot src/diagnose/engine.ts:51:69
 ❯ test/integration/http-transport.integration.test.ts:170:22

http-transport.integration.test.ts pointed its adapter at a pgboss schema that no suite creates — the version suite installs qd_it_v10/11/12, the graphile suite installs graphile_worker. So it read whatever an earlier run happened to leave in the database: green on a developer's long-lived container, red on CI's fresh one.

Not a flake and not a recent regression — it has failed on every integration run since it landed in abb244a (2026-08-06). The last green CI on main is f5df0a65.

The fix

  • The HTTP suite installs pg-boss into its own qd_it_http schema, the way the version suite does with its own.
  • The installer moves to a shared test/integration/pgboss-fixture.ts. It drops the schema before installing, so a second local run reads the database it built rather than the one the first run shaped — the same idempotency c672567 gave the graphile suite. The version suite now uses it too (−54 lines of duplicated setup).
  • Added expect(snapshot.probe.supported).toBe(true). Every assertion the test had would hold against a schema the transport could not read: the backend name comes from the adapter, findings is an array when the diagnosis is empty, and seen.length > 5 is met by the probe's own queries before anything reads a row. That is why it took a thrown error rather than a failed assertion to surface this.

Verification

Against a real Postgres 16 (postgres:16-alpine, same image CI uses):

  • npm run test:integration — 32/32 passed, all 3 files. Run twice back-to-back against the same database to confirm the drop-first fixture is idempotent.
  • Confirmed the failure reproduces first without the change (identical UnsupportedSchemaError).
  • npm run verify — lint, typecheck, 175 unit tests, build all pass.

No src/ changes; test setup only.


Generated by Claude Code

The HTTP-transport suite pointed its adapter at a `pgboss` schema no suite
ever created, so it read whatever an earlier run had left in the database.
That is green on a developer's long-lived container and red on CI's fresh
one, which is what it has been since it landed: every integration run on
main has failed with UnsupportedSchemaError.

It now installs pg-boss into its own `qd_it_http` schema, the way the
version suite does with its own. The installer moves to a shared fixture —
dropping the schema first, so a second local run reads the database it
built rather than the one the first run shaped — and the version suite uses
it too.

The suite also asserts `probe.supported` now. Every assertion it had would
hold against a schema the transport could not read: the backend name comes
from the adapter, `findings` is an array when the diagnosis is empty, and
the request count is met by the probe's own queries before anything reads a
row.
@ethanasm
ethanasm merged commit 2d1ab06 into main Aug 7, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants