A local-DX footgun found while browser-verifying #663. CI is unaffected and green — this only bites a local run.
What happens
playwright.config.ts reuses an already-running dev server when one is up (reuseExistingServer defaults on outside CI). Point pnpm test:e2e at a dev server that has been running for more than ten minutes and 11 of 16 specs fail, all cascading from:
Error: no seeded accounts returned
expect(records.length, 'no seeded accounts returned').toBeGreaterThan(0)
at e2e/smoke.spec.ts:55
Error: no seeded crm_account — the demo seed did not load
at seededAccountId (e2e/fixtures.ts:85)
The message is misleading: the seed loaded fine. The rows are simply not visible to the user the suite runs as.
Why
e2e/global-setup.ts signs up e2e-admin@hotcrm.test. That lands as a plain org member that owns nothing and holds no sharing grant. Under sharingModel: 'private' it can only read records it owns or has been shared.
On a cold CI database that is invisible, because nothing has claimed the seeds yet — every seeded row is ownerless, so the tolerant read succeeds and the suite passes. On a local dev server the demo_bootstrap schedule (*/10 * * * *) eventually fires and claims all ~115 seeded rows for the first user, and from that moment the e2e user reads 0 rows. pnpm demo:staff has the same effect for the same reason.
So the suite's green depends on a race it does not declare: the seeds must still be unowned when it runs.
Reproduce
pnpm demo:reset && pnpm devpnpm test:e2e immediately → passes- Wait for
demo_bootstrap to fire (≤ 10 min), or run pnpm demo:staff
pnpm test:e2e again → 11 failures
Confirmed identical on 17.0.0-rc.1 (origin/main worktree) and 17.0.0-rc.2, so it is not an upgrade regression — it is the suite's own environmental assumption.
Options (needs a deliberate call, hence an issue rather than a drive-by fix)
Each changes what the suite actually proves, so this is worth deciding rather than patching:
- Authenticate as the seeded dev admin (
admin@objectos.ai, already E2E_ADMIN_EMAIL/E2E_ADMIN_PASSWORD-overridable). Simplest, but the dev admin is documented as seeded on an empty DB in dev — needs checking that objectstack start, which is what CI's webServer runs, seeds it at all. If it does not, this trades a local failure for a CI one.
- Grant the e2e user access after sign-up (share, permission set, or make it the owner of what it creates and stop depending on seeded rows). Most faithful to "a normal user drives the app", and would make the specs independent of seed ownership entirely — but it is the largest change.
- Assert the precondition loudly. Keep the current model but fail in
global-setup.ts with "the seeded records are already owned; run pnpm demo:reset first" instead of letting 11 specs fail on a misleading message. Cheapest, and turns a confusing failure into an instruction — but leaves the race in place.
My inclination is (3) now and (2) when the specs are next touched, but the call is the maintainer's.
A local-DX footgun found while browser-verifying #663. CI is unaffected and green — this only bites a local run.
What happens
playwright.config.tsreuses an already-running dev server when one is up (reuseExistingServerdefaults on outside CI). Pointpnpm test:e2eat a dev server that has been running for more than ten minutes and 11 of 16 specs fail, all cascading from:The message is misleading: the seed loaded fine. The rows are simply not visible to the user the suite runs as.
Why
e2e/global-setup.tssigns upe2e-admin@hotcrm.test. That lands as a plain orgmemberthat owns nothing and holds no sharing grant. UndersharingModel: 'private'it can only read records it owns or has been shared.On a cold CI database that is invisible, because nothing has claimed the seeds yet — every seeded row is ownerless, so the tolerant read succeeds and the suite passes. On a local dev server the
demo_bootstrapschedule (*/10 * * * *) eventually fires and claims all ~115 seeded rows for the first user, and from that moment the e2e user reads0rows.pnpm demo:staffhas the same effect for the same reason.So the suite's green depends on a race it does not declare: the seeds must still be unowned when it runs.
Reproduce
pnpm demo:reset && pnpm devpnpm test:e2eimmediately → passesdemo_bootstrapto fire (≤ 10 min), or runpnpm demo:staffpnpm test:e2eagain → 11 failuresConfirmed identical on 17.0.0-rc.1 (
origin/mainworktree) and 17.0.0-rc.2, so it is not an upgrade regression — it is the suite's own environmental assumption.Options (needs a deliberate call, hence an issue rather than a drive-by fix)
Each changes what the suite actually proves, so this is worth deciding rather than patching:
admin@objectos.ai, alreadyE2E_ADMIN_EMAIL/E2E_ADMIN_PASSWORD-overridable). Simplest, but the dev admin is documented as seeded on an empty DB in dev — needs checking thatobjectstack start, which is what CI'swebServerruns, seeds it at all. If it does not, this trades a local failure for a CI one.global-setup.tswith "the seeded records are already owned; runpnpm demo:resetfirst" instead of letting 11 specs fail on a misleading message. Cheapest, and turns a confusing failure into an instruction — but leaves the race in place.My inclination is (3) now and (2) when the specs are next touched, but the call is the maintainer's.