test(e2e): invite-consumption registration flow (REGISTRATION_POLICY=invite) #392

New issue

Open

opened 2026-06-30 12:24:31 +00:00 by james · 0 comments

james commented

2026-06-30 12:24:31 +00:00

Owner

Deferred from the admin e2e spec (#326, PR #377).

Gap

The admin spec (apps/e2e/tests/admin.spec.ts) covers the admin-approval flow (register → pending → admin approves → login) and the invite mint/reveal/revoke UI, on a second app instance booted under REGISTRATION_POLICY=admin-approval. It does not cover full invite consumption — registering a second user with a minted invite code under REGISTRATION_POLICY=invite — because that policy is process-wide at boot and would need its own app instance.

Work

Add a third Playwright webServer instance + project under REGISTRATION_POLICY=invite (a third port + DB file; serve.sh is already env-parameterized from #326), mirroring the admin instance wiring in apps/e2e/playwright.config.ts.
Spec: first user registers (admin); admin mints an invite via the UI and copies the code; in a second context, a new uniqueEmail() user registers with the invite token (register.invite* fields) and lands authenticated; assert the invite is then marked consumed in the admin list. Cover the rejection paths too (no token → invite_required; reused token → invite_consumed).
Reuse the account.admin.* / register.invite* catalog values already added to apps/e2e/fixtures/strings.ts.

Note

Consider whether a third always-on instance is worth the CI cost vs. folding invite-consumption into the existing admin instance by other means; evaluate before committing to a third boot.

Deferred from the admin e2e spec (#326, PR #377). ## Gap The admin spec (`apps/e2e/tests/admin.spec.ts`) covers the **admin-approval** flow (register → pending → admin approves → login) and the **invite mint/reveal/revoke UI**, on a second app instance booted under `REGISTRATION_POLICY=admin-approval`. It does **not** cover full **invite consumption** — registering a second user *with* a minted invite code under `REGISTRATION_POLICY=invite` — because that policy is process-wide at boot and would need its own app instance. ## Work - Add a third Playwright `webServer` instance + project under `REGISTRATION_POLICY=invite` (a third port + DB file; `serve.sh` is already env-parameterized from #326), mirroring the `admin` instance wiring in `apps/e2e/playwright.config.ts`. - Spec: first user registers (admin); admin mints an invite via the UI and copies the code; in a second context, a new `uniqueEmail()` user registers **with** the invite token (`register.invite*` fields) and lands authenticated; assert the invite is then marked consumed in the admin list. Cover the rejection paths too (no token → `invite_required`; reused token → `invite_consumed`). - Reuse the `account.admin.*` / `register.invite*` catalog values already added to `apps/e2e/fixtures/strings.ts`. ## Note Consider whether a third always-on instance is worth the CI cost vs. folding invite-consumption into the existing admin instance by other means; evaluate before committing to a third boot.