fix(test): Postgres tests fail with relation "oauth_inits" already exists (missing from teardown list) #259

Closed
opened 2026-06-23 17:21:37 +00:00 by james · 0 comments
Owner

Symptom

PR / Test (postgres) has been failing on every PR since #215 was merged (08f177d, 2026-06-23). The SQLite leg passes; every other job passes; only Test (postgres) fails, deterministically, ~30–70s into the Run vitest step.

Root cause

apps/api/tests/db/_engines.ts keeps a hardcoded KYSELY_TABLES list of every table the migrator creates. Before each test suite's setup, that list is dropped (DROP TABLE IF EXISTS …) so the migrator can re-run cleanly against the shared Postgres database. SQLite uses :memory:, so each suite gets a brand-new DB and the list doesn't matter there.

Migration 012_oauth_inits (added in #215) introduced an oauth_inits table, but #215 did not add "oauth_inits" to KYSELY_TABLES. Consequence: on suite #2+ against the shared Postgres DB, the teardown drops everything except oauth_inits (including kysely_migration*), then the migrator re-runs from scratch and migration 012 trips over the leftover oauth_inits table:

error: relation "oauth_inits" already exists
  at Object.up db/migrations/012_oauth_inits.ts:53:5

Reproduced locally against postgres:16 in 73s.

Fix

One-line addition to KYSELY_TABLES in apps/api/tests/db/_engines.ts so the oauth_inits table is included in the teardown list.

Defence-in-depth follow-up (separate ticket if desired)

The failure mode is generic: any new migration that adds a table will trip this trap if the author forgets the teardown list. Options:

  • Query information_schema.tables and drop everything in the public schema rather than maintaining a hardcoded list.
  • Add a CI / unit assertion that KYSELY_TABLES is a superset of createTable(…) calls under apps/api/db/migrations/.

Deferring to a follow-up — this ticket is just the surgical fix to unblock CI.

Note on the unrelated ~10m02s infra hang

One recent run (#561) shows the runner-provisioning timeout pattern — eight jobs all failing at exactly 10m02s during the Set up job step. That's a separate Forgejo Actions infrastructure hang, not in scope here. It has occurred once in the last 20 failing Test (postgres) tasks; the dominant pattern is the migration teardown bug fixed in this PR.

## Symptom `PR / Test (postgres)` has been failing on every PR since #215 was merged (08f177d, 2026-06-23). The SQLite leg passes; every other job passes; only `Test (postgres)` fails, deterministically, ~30–70s into the `Run vitest` step. ## Root cause `apps/api/tests/db/_engines.ts` keeps a hardcoded `KYSELY_TABLES` list of every table the migrator creates. Before each test suite's setup, that list is dropped (`DROP TABLE IF EXISTS …`) so the migrator can re-run cleanly against the shared Postgres database. SQLite uses `:memory:`, so each suite gets a brand-new DB and the list doesn't matter there. Migration `012_oauth_inits` (added in #215) introduced an `oauth_inits` table, but #215 did not add `"oauth_inits"` to `KYSELY_TABLES`. Consequence: on suite #2+ against the shared Postgres DB, the teardown drops everything *except* `oauth_inits` (including `kysely_migration*`), then the migrator re-runs from scratch and migration 012 trips over the leftover `oauth_inits` table: ``` error: relation "oauth_inits" already exists at Object.up db/migrations/012_oauth_inits.ts:53:5 ``` Reproduced locally against `postgres:16` in 73s. ## Fix One-line addition to `KYSELY_TABLES` in `apps/api/tests/db/_engines.ts` so the `oauth_inits` table is included in the teardown list. ## Defence-in-depth follow-up (separate ticket if desired) The failure mode is generic: any new migration that adds a table will trip this trap if the author forgets the teardown list. Options: - Query `information_schema.tables` and drop everything in the public schema rather than maintaining a hardcoded list. - Add a CI / unit assertion that `KYSELY_TABLES` is a superset of `createTable(…)` calls under `apps/api/db/migrations/`. Deferring to a follow-up — this ticket is just the surgical fix to unblock CI. ## Note on the unrelated `~10m02s` infra hang One recent run (#561) shows the runner-provisioning timeout pattern — eight jobs all failing at exactly 10m02s during the `Set up job` step. That's a separate Forgejo Actions infrastructure hang, not in scope here. It has occurred once in the last 20 failing `Test (postgres)` tasks; the dominant pattern is the migration teardown bug fixed in this PR.
james closed this issue 2026-06-23 17:29:55 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
james/carol#259
No description provided.