Bernd Rodler
0f15132ec0
Phase 1 step 7 of VNCprodbuild. integration/tests/11-electron-notification.spec.ts launches the actual Electron shell, logs in as alice against this repo's existing docker-compose Stalwart fixture, injects a message over real SMTP (same helpers/smtp.ts sendMail() 02-mail-sync.spec.ts uses), and asserts a native notification fires via electron/main.ts's __notificationCallCount test hook - proving the full real pipeline, not just the synthetic IPC call step 3's smoke test exercises: SMTP -> Stalwart -> JMAP push (lib/jmap/client.ts) -> stores/email-store.ts's handleStateChange -> handleNewEmailNotification -> the page effect -> lib/electron-bridge.ts -> the contextBridge/IPC bridge -> electron/main.ts's Notification call. Runs against a `next dev` server (electron/main.ts's new ELECTRON_LOAD_URL escape hatch), not the standalone build, because this fixture's Stalwart is deliberately plain HTTP and production's CSP correctly refuses non-TLS connections - the identical trade-off integration/webmail.Dockerfile already makes for the browser-based suite. New playwright.integration-electron.config.ts + global-setup-electron.ts (brings up only the `stalwart` compose service, not `webmail`, which this suite never touches and which may not even be startable on a given host - see its own header comment) keep this fully separate from the main dockerized integration run, which has no Electron binary compatible with that container's platform; playwright.integration.config.ts gets a matching testIgnore so a plain `npm run test:integration` never tries to sweep this file in. Wired as `npm run test:integration:electron`. On "the real WebSocket path": confirmed against this fixture's actual `stalwartlabs/stalwart:v0.16` (same as the sandbox server) that its /jmap/ws requires the same Authorization header as every other JMAP endpoint on the handshake itself, which the browser WebSocket API cannot attach - so the WS attempt reaches the network correctly (see the CSP fix in the previous commit) but always fails auth here, and the circuit breaker falls back to SSE within about a second. That fallback is what delivers the push this test observes - documented in detail in the spec's header comment, including why asserting the WS handshake itself succeeds here would be asserting something that cannot be true from a browser against this specific server. Known flakiness, root-caused not eliminated (see playwright.integration-electron.config.ts's retries: 2 and its comment): `next dev`'s on-demand route compilation + Fast Refresh occasionally races the SSE stream during the login -> inbox transition and drops that one push event with no error anywhere - reproduced by running the identical test repeatedly against an already-warm stack (IT_NO_DOCKER=1): identical request sequence logged every time, but the outcome wasn't always the same. This is specific to the dev-server workaround this test needs for the plaintext-Stalwart fixture, not a bug in the feature it's verifying - the WS circuit breaker and SSE fallback fire exactly as designed in every run's own logs, pass or fail. Verified: passed cleanly standalone multiple times; with retries: 2 in place, passed within the retry budget on every attempt made.
12 lines
254 B
Plaintext
12 lines
254 B
Plaintext
# Local docker env (copied from .env.example)
|
|
.env
|
|
|
|
# Arch-specific stalwart-cli binary, fetched by stalwart/prepare-stalwart-cli.sh
|
|
stalwart/stalwart-cli
|
|
|
|
# Playwright/test artifacts
|
|
node_modules/
|
|
test-results/
|
|
test-results-electron/
|
|
playwright-report/
|