fix(sdp-api): create the test database before running pnpm test#488
fix(sdp-api): create the test database before running pnpm test#488moviendome wants to merge 5 commits into
Conversation
On a fresh clone the documented setup (`pnpm db:postgres:up` +
`pnpm --filter @sdp/api db:postgres:bootstrap`) creates the `sdp`
database but never `sdp_test`. The workers pool binds `sdp_test` but
does not create it, and the `test` script never ran the step that
would, so `pnpm test` failed every workers file with Postgres
`FATAL 3D000` ("database \"sdp_test\" does not exist").
Chain the existing `db:migrate:test` into `test`. It is idempotent:
`ensureDatabaseExists` guards `CREATE DATABASE` behind a
`pg_database` existence check and migrations report "up to date", so
re-runs are a fast no-op.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@moviendome is attempting to deploy a commit to the Solana Foundation Team on Vercel. A member of the Team first needs to authorize it. |
Greptile SummaryThis PR fixes the missing database setup step that caused
Confidence Score: 5/5This is a minimal, targeted fix: a single-line change that prepends an idempotent database-setup step to the The one-line change is correct, the idempotency of No files require special attention. The sibling scripts ( Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[pnpm test] --> B[pnpm db:migrate:test]
B --> C{sdp_test exists?}
C -- No --> D[CREATE DATABASE sdp_test]
D --> E[Run migrations]
C -- Yes --> F[Migrations up to date — no-op]
E --> G[pnpm test:workers]
F --> G
G --> H[pnpm test:node]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[pnpm test] --> B[pnpm db:migrate:test]
B --> C{sdp_test exists?}
C -- No --> D[CREATE DATABASE sdp_test]
D --> E[Run migrations]
C -- Yes --> F[Migrations up to date — no-op]
E --> G[pnpm test:workers]
F --> G
G --> H[pnpm test:node]
Reviews (5): Last reviewed commit: "Merge branch 'main' into fix/test-create..." | Re-trigger Greptile |
|
@moviendome sweet, thanks |
|
working on getting this merged |
Great! Thx 🚀 |
While setting up a fresh clone to keep contributing,
pnpm testfailed before running a single test. This chains the one missing setup step so the documented flow works, and corrects a diagnostic that pointed the wrong way.What happens today
On a clean checkout, the documented setup:
fails right away:
Every workers test file fails the same way.
Root cause
db:postgres:bootstrapcreates and migratessdp, but nothing createssdp_test. The workers pool (vitest.workers.config.ts) bindssdp_testbut doesn't create it, and thetestscript (pnpm test:workers && pnpm test:node) never ran the step that would. That step already exists:db:migrate:testcreates and migratessdp_testviaensureDatabaseExists. It just wasn't chained in.What this changes
apps/sdp-api/package.json— chain the existing step intotest:"test": "pnpm db:migrate:test && pnpm test:workers && pnpm test:node"db:migrate:testis idempotent:ensureDatabaseExistsguardsCREATE DATABASEbehind apg_databaseexistence check, and migrations report "up to date" when there's nothing new. So on a machine that already hassdp_test, the chained step is a fast no-op.Testing
Verified end to end on a fresh clone (v0.31.0):
pnpm testfails every workers file with3D000/ "database sdp_test does not exist"sdp_testand runs green past the DB layer (727 passed)db:migrate:testprints "Test postgres migrations are up to date" and the suite runs again with no DB error, confirming the no-op pathbiome checkon the changed file is clean.CI
No CI changes needed. The fork-safe runner (
scripts/run-workspace-tests.mjs) already runsdb:migrate:testbefore the suite, so chaining it intotestis a duplicate idempotent no-op there; on the Doppler path it adds the same idempotent step against the CI Postgres service. Either way it's the no-op described above, and the PR's own run exercises it.