fix(scripts): the e2e helper connects to a different database than the app under test #273

New Issue

2026-09-02T17:11:18-05:00

bermudalamb commented

2026-09-02 17:11:18 -05:00

frontend/tests/e2e/support/db.ts opens its own connection — the password-reset specs read a token straight out of the database. Nothing guarantees that connection points at the same database the application is using, and right now it usually does not.

Two separate faults.

1. `-E2eDb` moves the app but not the helper

Introduced by #186. start-local.ps1 -E2eDb runs the stack against redefined_e2e on 55501, but db.ts defaults to redefined_local on 55500 and run-tests.ps1 -Suite e2e sets nothing. So the application writes to one database and the suite reads another.

I did not hit this while building #186 because I set TEST_PGHOST/PORT/USER/PASSWORD/DATABASE by hand on every run. The supported path has never been exercised, which is the part that should have been obvious.

2. `-Suite all` leaks the integration database into the e2e run

Pre-existing, and independent of the above. Invoke-IntegrationSuite sets $env:TEST_PGPORT = "$TestDbPort" (55432) and PowerShell keeps that for the rest of the session, so the e2e run that follows inherits it — but not the matching user, password or database name, which stay at their redefined_local defaults. The helper then tries redefined_local credentials against the integration database on 55432 and fails to connect.

Fix

Make the database the stack is using a fact rather than a convention. start-local.ps1 already writes .local/pids.json; have it also record the coordinates it actually used, and have run-tests.ps1 -Suite e2e read them and set TEST_PG* from that.

That removes the whole class of mismatch: there is one place the answer comes from, it is written by the thing that made the decision, and a stale or missing file is a clear failure rather than a silent connection to the wrong data.

Setting them explicitly in Invoke-E2eSuite also overrides the leak from fault 2, so both are closed by the same change.

Verification

-Suite e2e after start-local.ps1 -E2eDb must run the password-reset specs green, since those are the ones that read through the helper. Running -Suite all must not change which database the e2e run uses.

Found while verifying #116.

`frontend/tests/e2e/support/db.ts` opens its own connection — the password-reset specs read a token straight out of the database. Nothing guarantees that connection points at the same database the application is using, and right now it usually does not. Two separate faults. ## 1. `-E2eDb` moves the app but not the helper Introduced by #186. `start-local.ps1 -E2eDb` runs the stack against `redefined_e2e` on 55501, but `db.ts` defaults to `redefined_local` on 55500 and `run-tests.ps1 -Suite e2e` sets nothing. So the application writes to one database and the suite reads another. I did not hit this while building #186 because I set `TEST_PGHOST/PORT/USER/PASSWORD/DATABASE` by hand on every run. The supported path has never been exercised, which is the part that should have been obvious. ## 2. `-Suite all` leaks the integration database into the e2e run Pre-existing, and independent of the above. `Invoke-IntegrationSuite` sets `$env:TEST_PGPORT = "$TestDbPort"` (55432) and PowerShell keeps that for the rest of the session, so the e2e run that follows inherits it — but not the matching user, password or database name, which stay at their `redefined_local` defaults. The helper then tries `redefined_local` credentials against the integration database on 55432 and fails to connect. ## Fix Make the database the stack is using a fact rather than a convention. `start-local.ps1` already writes `.local/pids.json`; have it also record the coordinates it actually used, and have `run-tests.ps1 -Suite e2e` read them and set `TEST_PG*` from that. That removes the whole class of mismatch: there is one place the answer comes from, it is written by the thing that made the decision, and a stale or missing file is a clear failure rather than a silent connection to the wrong data. Setting them explicitly in `Invoke-E2eSuite` also overrides the leak from fault 2, so both are closed by the same change. ## Verification `-Suite e2e` after `start-local.ps1 -E2eDb` must run the password-reset specs green, since those are the ones that read through the helper. Running `-Suite all` must not change which database the e2e run uses. Found while verifying #116.

bermudalamb referenced this issue

2026-09-02 18:27:27 -05:00

The e2e suite and the backend integration suite share one database, and the integration suite truncates it #116

bermudalamb referenced this issue from a commit

2026-09-03 16:58:52 -05:00

fix(scripts): make the database the e2e suite reads a recorded fact (#273)

bermudalamb referenced a pull request that will close this issue

2026-09-03 16:59:09 -05:00

fix(scripts): make the database the e2e suite reads a recorded fact (#273) #291

bermudalamb closed this issue

2026-09-03 16:59:17 -05:00

bermudalamb referenced this issue from a commit