3 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	42f7bd651d	test(e2e): isolate runs and identities without a new backend endpoint (WP-74) ... The three specs shared one mutable backend and said so in their own comments ("Restart the backend between CI runs"). WP-70 recorded the fix as a dev-only seed endpoint; it isn't needed. The DB path already routes through IConfiguration, so playwright.config's webServer hands the backend a throwaway SQLite file per invocation — the same trick TestWebApplicationFactory already uses, with zero backend change. And StubIdentityProvider already honoured X-Subject; the only gap was that nothing sent it. That matters because the backend has no IsDevelopment() gate anywhere, so a seed endpoint would have had to invent the codebase's first environment gate. subjectInterceptor mirrors the existing roleInterceptor and is wired into the same isDevMode()-only list. Interceptors alone were not enough: the raw XHR upload and the hand-written letter-preview fetch bypass Angular's chain (as CLAUDE.md documents), so both now stamp X-Subject explicitly — without that, every uploaded document still landed under DemoOwner. reuseExistingServer stays on: flipping it would break local runs for anyone already serving the docker stack. Each run gets a unique DB filename and global-setup sweeps only prior runs' leftovers — deleting a fixed path mid-run risks SQLite silently recreating an empty, unmigrated file under fullyParallel. Verified: e2e passes twice back-to-back with no backend restart, and X-Subject was observed on a real request, not merely wired. brief-v2.spec.ts keeps the shared identity for now — see the KNOWN GAP note; a backend staleness bug makes /brief/preview return a sent letter with the draft watermark for any non-DemoOwner BSN. actors.ts reserves the actor for whoever fixes it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-19 16:32:07 +02:00
ehoandClaude Opus 4.8	2820cd3476	fix(ci): e2e — let Playwright manage both servers (fixes the 2-hour hang) ... The e2e job backgrounded `dotnet run &` and `ng serve &` in separate Actions steps, then `npx wait-on` (no timeout) in a later step. A process started with `&` in one step is killed when that step's shell exits, so wait-on waited forever on servers that were already gone — the job hung until the runner's hard limit (~2h; Gitea's act_runner doesn't reliably enforce timeout-minutes). Move both servers into Playwright's `webServer` (an array: backend + `npm start`), so Playwright starts them, waits for readiness, runs the suite, and tears them down in the one `npm run e2e` process — CI and local alike. The CI e2e job is now just npm ci / playwright install / npm run e2e. `reuseExistingServer` is on locally (reuses a running app, incl. the docker stack) and off in CI (fresh start). Verified locally via `CI=1 npm run e2e` against free ports + a clean db: both smoke tests pass in ~15s (no hang). The earlier local failure was leftover SQLite state (WP-22) from a dirty run resuming a Concept — CI checks out fresh, so its db is always empty. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 20:07:35 +02:00
ehoandClaude Sonnet 5	26c2c5acd0	feat(fp): WP-19 — Playwright e2e smoke against the real FE+backend ... Adds a happy-path spec (login → dashboard → registratie wizard, including a real identity-document upload → real submit) and a degraded-path spec (?scenario=error → <app-async> error slot → retry), both driving the real app against the real .NET backend, plus a CI job that boots both. Writing the retry spec surfaced a real bug: AsyncComponent's retry() only reloads a [resource]-fed instance, so every real page (all [data]-fed via a store's RemoteData) had a silently no-op retry button. Added a retryClicked output and wired it on the dashboard's two async blocks. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-04 10:13:40 +02:00