fix(ci): get CI green — CSP, test-hooks wire, e2e helpers, browser tests, sequential Playwright#397
Merged
Merged
Conversation
server_fn 0.8 uses wasm-streams 0.5, aligning with reqwest's wasm-streams 0.5 (pulled by iroh-relay). This kills the duplicate-symbol link error that has been silently breaking CI Browser tests under bash -e (no pipefail). After this lands, ui/phase-3a-composer rebases on main and its 39 browser tests will run on CI for the first time. Verified: cargo tree -i wasm-streams --target wasm32-unknown-unknown returns a single version (0.5.x). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Steps with `id:` set on this runner inherit a shell of `bash -e {0}`
(no pipefail), so `cmd 2>&1 | tee /tmp/log` masks the upstream exit
code — `tee` always returns 0 and the step is reported as success
even when the actual command died.
Discovered while auditing browser test runs: ui/phase-3a-composer
shows `error: linking with rust-lld failed` followed by a green
conclusion, and the same is true for recent main-branch runs. The
duplicate-symbol link error from two `wasm-streams` versions has
been live for some time but invisible because the step "passes."
Fix is mechanical: force `bash --noprofile --norc -eo pipefail {0}`
on every tee-piped step (Clippy, Test, Browser tests, Playwright
E2E) so the upstream exit code surfaces.
Note: this commit will likely turn Browser tests RED on this PR —
that's the correct outcome. The dep skew between
`wasm-streams 0.4.2` (Leptos -> server_fn) and
`wasm-streams 0.5.0` (iroh -> reqwest) needs a separate fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two latent issues surfaced once the wasm-pack test binary actually ran
to completion (CI was previously masking the link error so this whole
mod was effectively unmonitored).
1. `foundation.css` ships an `@import url('https://fonts.googleapis.com/...')`
for Fraunces/Plex/JetBrains. Headless Firefox under wasm-pack has no
network access and the @import stalls/cancels the entire stylesheet,
leaving every `:root` custom property unresolved. Strip @import lines
before injecting the CSS into `<style>` so token resolution works
offline. The fonts are irrelevant to token assertions.
2. `style.css` redeclared `--focus-ring: var(--focus-ring, …)` on the
same `:root` selector that already inherits the token from
`foundation.css`. A same-selector self-reference is a custom-property
dependency cycle, which CSS resolves to the guaranteed-invalid value
— blanking `--focus-ring` everywhere it's consumed (focus outlines,
button/state styling). Drop the redundant declaration; foundation.css
owns the token.
The bug also explains why focus rings on the deployed app may have looked
weaker than the spec since phase-0 — same-selector cycles are silent,
they just produce empty values.
Restores all three `foundation_tokens` browser tests:
- foundation_palette_tokens_defined
- legacy_bg_main_aliases_bg_0
- data_accent_swap_changes_moss_2
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…te contract Phase 2a (commit 77ce56e) shipped two ad-hoc spans for the message-row inline queue hint: <span class="queue-note queue-note--pending"> queued · will send on reconnect </span> <span class="queue-note queue-note--late"> sent earlier · arrived now </span> Phase 2b (commits 357e128 + 9535748) replaced both with a shared `<InlineQueueNote>` component that consumes spec-pinned copy from `sync_queue_copy` and renders `.inline-note.inline-note--{queued,inbound-held}`. The Phase 2a tests were never updated to follow that refactor; with the CI mask now lifted they fail because the old class names + the legacy `queued · will send on reconnect` copy no longer exist. Update both row tests to assert the live contract: - `queue_note_late_renders_hint` now queries `.inline-note.inline-note--inbound-held`. - `queue_note_pending_renders_hint_and_badge` queries `.inline-note.inline-note--queued` and asserts the spec copy from `sync_queue_copy::msg_note_queued("Mira")` (`queued · will send when Mira reachable`, per `docs/specs/2026-04-19-ui-design/sync-queue.md` §Copy / msg_note_queued_peer). `.queued-badge` + `.message--pending` checks are unchanged — those classes still flow from `message.rs` as before. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…n frames The 6 reconnection-toast / welcome-back-banner tests pre-set `device_online = false`, mount the component, then schedule the `device_online → true` flip inside `request_animation_frame`. They relied on `tick().await; tick().await;` (each a `setTimeout(0)`) being enough wall-clock time for that RAF callback to fire before the assertions ran. That assumption is wrong under wasm-pack's headless Firefox harness. Every `#[wasm_bindgen_test]` runs in the same browser tab, so prior tests leave RAF callbacks, gloo timers, and forgotten leptos owners behind. Under enough load the next test's RAF can sit in the queue past two `setTimeout(0)` resolutions, leaving the toast/banner unmounted when the test asserts. Locally this manifested as a ~⅓ flake on `reconnection_toast_dismiss_button_hides_toast` and `reconnection_toast_fires_after_60s_offline`; on CI the same flake sometimes hit the welcome-back-banner pair. Add `await_animation_frame()` — a Future that resolves when the browser actually dispatches the next RAF — and inject one between the two `tick()` calls in every transition-driving test. Now the sequence is deterministic: tick // initial Effect run with prev=true, online=false await_animation_frame // fence — the queued RAF closure has fired tick // reactive flush of the false→true transition Three sequential phase_2b runs and two full-suite runs (304 tests each) go green after this change. No production code touched — the bug is purely a test-harness synchronization gap. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "server gear" button was renamed to the "grove header" during the UI redesign; production code in channel_sidebar.rs:266-270 renders the button with `class="grove-header sidebar-header"` and `aria-label="grove menu"`, with no `.server-gear-btn` anywhere in crates/web/src/. The e2e tests + helpers kept the old selector. CI hid the failure because Browser tests + E2E both ran under bash -e (no pipefail) and the | tee pipe masked the exit code. With the pipefail fix on this PR, 7 mobile-chrome E2E tests fail on the same locator timeout. Switch to the semantic [aria-label="grove menu"] selector — robust to class drift, works on both desktop and mobile shells. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`e2e/cross-browser-sync.spec.ts` launches both Chromium and Firefox to
verify cross-browser P2P connectivity, but `scripts/setup-e2e.sh` only
installed Chromium. Firefox-launching tests failed with:
browserType.launch: Executable doesn't exist at
/home/runner/.cache/ms-playwright/firefox-1509/firefox/firefox
Mirror the existing Chromium install block — same filesystem guard so
re-runs skip the download. Skip `--with-deps` for the same reason as
Chromium (sudo prompt is non-interactive in CI sandboxes).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The `.net-status-footer` selector no longer exists in production code — `grep -r net-status-footer crates/web/src` is empty. The mobile branch of the same OR-locator (`.mobile-top-bar`) still works, so only the desktop project (which renders the desktop shell) was failing. The test's intent is "the app shell rendered after server creation, proving the network came up enough for the client to join a server and mount the channel surface." On desktop the always-mounted equivalent is `.main-pane-header` (the channel header). Use it. Reachability and queue depth indicators (`.relay-signal-button`, `.offline-strip`) live inside the sync-queue panel which only mounts on demand, so neither is a stable "app loaded" proxy at this point. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The members pane is closed by default. `setupTwoPeers` opens it only briefly to wait for display-name sync, then `closeMemberList` collapses it again — `.right-rail` switches `data-open` to "false" and the `match which.get()` branch unmounts MemberList entirely (right_rail.rs). Counting `.member-item` against the closed pane returned 0, failing the `toBeGreaterThanOrEqual(2)` assertion. Open the pane explicitly via `openMemberList` and poll the count instead of a fixed `waitForTimeout(1000)` so we don't race against member-sync completion. After `kickPeer` toggles the pane during its own flow, re-open it before re-counting. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three Playwright tests timed out waiting for channels to gossip through
the relay after a `joinViaInvite`:
- `multi-peer-sync.spec.ts:48` (desktop+mobile) — pre-existing channels
visible after join. Setup pre-creates two channels, then peer 2 joins.
Three sequential `toBeVisible({ timeout: 30_000 })` assertions on top
of fresh-start + invite + join can total > 120 s on CI.
- `multi-peer-mobile.spec.ts:43` — `setupTwoPeers` failed inside
`joinViaInvite` waiting for `.channel-item` (20 s). First-channel
arrival via gossip can take 30+ s when the relay is recovering from
the previous serial test's teardown.
Bump the post-join `.channel-item` wait inside `joinViaInvite` from 20 s
to 60 s so the helper itself doesn't flake. Bump per-describe timeout
on the two affected specs from 120 s to 180 s for the compounded budget.
These are timing-only fixes — no behavioural change. Selectors,
production code, and assertions stay identical. The fast happy path
(first-channel visible immediately) still resolves immediately.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…gets
The kick + display-name-dependent multi-peer specs failed because the
joining peer broadcast the literal "anonymous" fallback to the inviter,
not their actual display name. Root cause: `setupTwoPeers` calls
`getPeerId(page2)` before `joinViaInvite(page2, code, 'Bob')`. The
former invokes `advancePastNameStep` with no display name, advancing
WelcomeScreen step Name → Action and unmounting `.welcome-name-input`.
The latter then calls `advancePastNameStep('Bob')` which no-ops because
the input element is gone. AddServerPanel's join-confirm closure reads
an empty `display_name` signal and `add_server.rs:163-167` substitutes
the string `"anonymous"` — which is what the inviter's MemberList shows
and what `kickPeer('Bob').waitFor` cannot ever satisfy.
Fix:
- `getPeerId(page, displayName?)` — when the caller intends to
`joinViaInvite` afterward, fill the name on welcome step 1 BEFORE
advancing. The signal then survives the step transition and the
later `advancePastNameStep` no-op is harmless.
- `setupTwoPeers` now forwards `peer2Name` to `getPeerId`.
- `multi-peer-sync.spec.ts` "pre-existing channels" path also calls
`getPeerId(page2, 'Bob')` directly.
- `setupTwoPeers` display-name-sync wait raised 20 s → 60 s and
switched from warn-and-continue to throw. The previous silent warn
produced misleading downstream timeouts on every kick/trust call.
Test-budget bumps for the same gossip-headroom reason as 7f88280
(which lifted helper waits but left these specs at 120 s):
- `permissions.spec.ts` 120 s → 180 s — `setupTwoPeers` + member-list
poll + kick + re-poll runs past 120 s on slow CI.
- `cross-browser-sync.spec.ts` 120 s → 180 s — double-browser launch +
joinViaInvite + warmup + bidirectional message round-trips.
- `multi-peer-sync.spec.ts` 180 s → 240 s — pre-existing-channels test
compounds 60 s display-name wait + three serial 30 s channel waits;
was timing out at 180 s in repeated runs.
- `join-links.spec.ts` peer-joins-via-link gets `test.setTimeout(180_000)`
— its own internal waits (60 s + 30 s + 30 s) already exceed the
60 s default test budget.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
… waits The previous run on this branch (PR #397) still failed five tests. Reproduced locally and traced each cause: 1. `createChannel` helper used stale `.channel-create-input` selectors. The "new" button now opens a tree-kind picker (text/voice/temp) before the name input renders, and the name input is `.tree-slot__input` (channel_sidebar.rs:317-384). Helper hung 240 s on the missing locator, killing every test that creates a channel mid-session (multi-peer-sync `pre-existing channels`, `new channel mid-session`, `messages in non-general channel sync`, `rapid channel creation`, and the corresponding multi-peer-mobile cases). Fix: open picker → click 'text' → fill `.tree-slot__input` → Enter. 2. `cross-browser-sync.spec.ts` clicked an unscoped `[aria-label="grove menu"]`. Both `.shell-desktop` and `.shell-mobile` mount that button (`display: none` on the inactive shell still keeps it in the DOM), so Playwright's strict mode threw on the duplicate match. Scope to the visible shell + `.first()`. 3. `permissions.spec.ts:79` (kicked peer messages) used `sendMessage` on the kicked peer. After kick, Bob's own broadcast is rejected by his local DAG (no `SendMessages` permission), the message body never renders locally, and `sendMessage`'s own-message `waitFor` times out in 10 s. The test only cares that Alice does NOT receive the message — drive the composer directly (fill + press Enter) and skip the own-render assertion. 4. Mid-session channel-arrival waits were too tight on slow CI: - multi-peer-sync `new channel`, `dev`, `chan-a/b`: 30 s → 60 s. - multi-peer-mobile `mobile-news`, `mobile-dev` toBeAttached: 60 s → 120 s (60 s was hitting the ceiling at 1.2 m). Pre-existing channels arrive in the initial state replay on `accept_invite` so they're fast; mid-session events have to gossip through the relay and routinely take 30+ s under load. 5. `join-links.spec.ts:10` `pageB.waitForSelector('.app-shell, …')` 60 s → 120 s. Join-via-URL does a fresh-start of peer B's client (full IDB clear + reload + WASM bootstrap + relay handshake + accept_invite + initial sync); 60 s was tight. 6. `cross-browser-sync.spec.ts` describe-level `setTimeout` 180 s → 240 s, matching the multi-peer-sync ceiling. Two browser-engine launches + joinViaInvite + warmup + bidirectional message round- trips compounded past 180 s on slow CI. Local re-verification (single-shell setup + run): the four basic multi-peer tests that previously timed out at 240 s now pass in 7-11 s on both desktop-chrome and mobile-chrome, and the kick test passes cleanly. Cross-browser, join-links and the mid-session channel cases get the headroom they need. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…ssage Second-pass fixes after the createChannel/scoped-grove-menu commit. Local re-run brought the suite from 5 → 4 failed, 27 → 32 passed. Remaining failures all map to: - Mobile-chrome cross-peer message sync taking 30+ s on slow CI in non-default channels (mid-session gossip mesh hasn't fully settled by the time the first sendMessage fires). Bump waitForMessage 30 s → 60 s in `multi-peer-sync.spec.ts:117`, `multi-peer-mobile.spec.ts:69`, `multi-peer-mobile.spec.ts:89`, and the cross-browser specs to match the channel-arrival ceiling. - `cross-browser-sync.spec.ts:41` spent 240 s stuck because the test left the grove drawer OPEN after the visibility check, then called sendMessage. The drawer overlay sits on top of `.mobile-home` so the helper's auto-push click was blocked from the channel row, freezing on the input-visibility wait. Close the drawer immediately after the visibility check. - `join-links.spec.ts:10` post-join `.channel-item` toBeAttached 30 s → 60 s. The join-via-URL flow's initial sync delivers the channel events but on slow CI the relay round-trip can stretch past 30 s before `general` reaches B's DOM. Same logic for the `Welcome Bob!` waitForMessage at the end (30 s → 60 s). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Three of the remaining four failures from the previous run were the
helper's local own-message render wait timing out at 10 s:
cross-browser-sync.spec.ts:104 sendMessage('warmup') → 10 s
permissions.spec.ts:217 sendMessage('mismatch still…') → 10 s
multi-peer-sync.spec.ts:139 sendMessage('bob in dev too') → 10 s
Own-message render is local (not gossip-dependent), but on
mobile-chrome under load the chat-list reactive update routinely
takes 10-20 s to flush after the input handler dispatches the
event. The 10 s ceiling was tight even on desktop-chrome — the
permissions `mismatch` flake hit it too.
Bump the helper's own-render `waitFor` to 30 s. Doesn't slow the
fast happy path (the locator resolves immediately when the body
appears); only changes the worst-case bail-out window.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Per review feedback: stop bumping numeric timeouts as a workaround for
flaky waits, switch to deterministic event-based signals.
The previous own-render check polled the rendered chat list for the
just-sent message body. That signal is event-based but indirect — the
chat-list update depends on signal flush order, list virtualisation,
and scroll position. On mobile-chrome under load the tail routinely ran
10-20 s, and the helper's 10-30 s ceiling kept being the wrong shape
of fix (kept hitting the bound across runs).
The composer clears its input synchronously when `send_message`
completes, so the input element going from `text` → `''` is a
deterministic post-send signal — it fires the moment the local DAG
apply returns, regardless of whether the rendered list has flushed.
`expect(input).toHaveValue('')` is event-based polling on that signal.
Also dropped the 400 ms sleep in the mobile-push branch; wait for the
`.mobile-push--channel` container to mount instead.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
# Conflicts: # crates/web/tests/browser.rs # e2e/cross-browser-sync.spec.ts # e2e/helpers.ts # e2e/multi-peer-sync.spec.ts
… to event-based waits
After merging main's PR-2 event-based-waits infrastructure (Peer wrapper
+ __willowEvent push stream + waitUntilHeadsEqual), port the real bug
fixes from this branch onto the new helpers structure and migrate the
remaining specs to use Peer.waitUntilHeadsEqual / Peer.nextEvent.
helpers/ui.ts createChannel
- Rewrite for the kind-picker UI: click `.tree-kind-picker__item` text
before filling `.tree-slot__input`. The previous one-shot fill on
`.channel-create-input` hung 240 s on every mid-session-channel test
because the selector no longer exists (channel_sidebar.rs:317-384).
helpers/peers.ts getPeerId(page, displayName?) + setupTwoPeers
- Accept a `displayName` so the welcome step-1 captures it BEFORE the
name input unmounts. setupTwoPeers now passes peer2Name to getPeerId.
Without this, joinViaInvite's own `advancePastNameStep(displayName)`
no-ops (the input is already gone) and the join-confirm closure
reads an empty `display_name` signal — peer 2 broadcasts the literal
string "anonymous" (add_server.rs:163-167) and Alice's MemberList
shows `unknown peer` even after gossip lands.
multi-peer-mobile.spec.ts
- Migrate to `./test-hooks` and use `peer(page, label)`.
- Replace `waitForMessage(…, 60_000)` + DOM polling with
`bob.nextEvent(MessageReceived & !isLocal)` for cross-peer arrival
and `bob.waitUntilHeadsEqual(alice)` for channel sync.
- Drop `waitForTimeout(400|500|1500)` sleeps; wait for the actual
`.mobile-push--channel` mount instead.
permissions.spec.ts (kicked-peer + compare-mismatch)
- Migrate to `./test-hooks`. Replace `waitForTimeout(2000)` post-kick
with `bob.waitUntilHeadsEqual(alice)` — once Bob's heads include the
kick event, his local DAG rejects further sends. Replace the
cross-peer 30 s waitForMessage in compare-mismatch with
`alice.nextEvent(MessageReceived)` + default DOM check.
join-links.spec.ts
- Migrate to `./test-hooks`. Replace 60 s `.app-shell` + 60 s
`.channel-item` + 60 s `waitForMessage` waits with
`bob.waitUntilHeadsEqual(alice)` (post-join initial sync) +
`bob.nextEvent(MessageReceived)` for the welcome message. Default
120 s test budget covers two-peer setup; 180 s no longer needed.
cross-browser-sync.spec.ts (mobile Chrome ↔ desktop Firefox)
- Migrate to `./test-hooks`. Wire the `peer` factory before the first
goto on each launched-browser context so addInitScript takes effect.
- Fix the `.server-gear-btn` selector — the button is now
`[aria-label="grove menu"]`. Scope to the visible shell to avoid
Playwright's strict-mode duplicate-match guard.
- Pass display names to `getPeerId(...)` (same anonymous bug as above).
- Replace cross-peer `waitForMessage(…, 30_000)` with `nextEvent`.
- Replace `waitForTimeout(500)` settle-sleeps after Generate Invite /
Back with `expect(invite).not.toHaveValue('')` and a wait for the
channel sidebar / mobile-home to mount.
wait-timeout baseline ratchet 53 → 39
- Locks in the 14-call reduction so the next migration can only
improve from here.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The Content-Security-Policy meta tag added in #462 forbids inline scripts (`script-src 'self' 'wasm-unsafe-eval' 'unsafe-eval'` — no `'unsafe-inline'` and no script hash). `trunk serve` injects an inline auto-reload bootstrap into `dist/index.html` that opens a WebSocket back to trunk for HMR; under the new CSP that script is blocked, so the WASM module never boots and every spec stalls at the "Loading Willow…" splash until `waitForApp` times out at 30 s. `--no-autoreload` skips the inline-script injection. The dist files trunk serves are otherwise identical, so the e2e suite gets a working app while keeping the CSP intact. Reproduced locally: every spec failed at exactly 30.4 s on `page.waitForSelector('.welcome-screen, .shell-desktop .app, …')`, with `document.body.innerText === "Loading Willow…"` and `window.__willow === undefined`. Browser console showed: Executing inline script violates the following Content Security Policy directive 'script-src 'self' 'wasm-unsafe-eval' 'unsafe-eval'. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Trunk's WASM bootstrap is an inline `<script type="module">` it injects into the rendered `index.html` at build time. The CSP added in #462 forbids inline scripts (`script-src 'self' 'wasm-unsafe-eval' 'unsafe-eval'` — no `'unsafe-inline'`, no script hash, no nonce), so under setup-e2e the bootstrap is blocked, the WASM module never executes, and every Playwright spec hangs at the "Loading Willow…" splash until `waitForApp` times out at 30s. The previous `--no-autoreload` commit dropped the dev-mode reload script but left the bootstrap in place — that was diagnosed but incomplete. This commit: 1. Generates a `crates/web/index.test.html` from `index.html` with `'unsafe-inline'` appended to the `script-src` directive. 2. Points `trunk build` / `trunk serve` at it via positional `index.test.html` plus `--html-output index.html` so the served URL stays `/` and the WASM still loads. 3. Adds the generated file to `.gitignore`. The source `crates/web/index.html` is untouched, so the `static_assets::index_html_declares_content_security_policy` gate still enforces the strict CSP for production builds. Production's own bootstrap-vs-CSP conflict is the same root cause but lives behind nginx and is out of scope here — call that out so the next person doesn't think this fix covers it. Verified locally: full suite now runs to completion (14 passed, 8 failed, 29 skipped — all CSP-blocked timeouts gone; remaining failures are unrelated multi-peer-sync / kick / Firefox issues that need separate triage). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Two unrelated bugs surfaced by yesterday's first full e2e run.
1. `WillowTestHooks::{heads, snapshot}` were serialising via
`serde_wasm_bindgen::to_value`, which renders Rust `BTreeMap` and
`HashMap` as JS `Map` instances. The TypeScript bindings type heads
as `Record<string, AuthorHead>` and the test does
`Object.keys(snap.heads)` — on a `Map`, that returns `[]`, so
`expect(...).toBeGreaterThan(0)` failed even though the DAG had
events. Fix: serialise via a `Serializer::new().serialize_maps_as_objects(true)`
helper (`js_object_serializer`) so heads round-trips as a plain
object. Cascades into every `waitUntilHeadsEqual` caller — its
internal `canonicalHeads` JSON-stringifies via `Object.keys`, which
is silently empty for both peers, and the predicate equality used
to spuriously hold while the underlying heads disagreed.
2. `openServerSettings` looked for `.server-gear-btn`, which the
vibe-annotations UI pass (0861f26) removed when it folded the gear
into the grove-header. The button now fires `on_server_settings_click`
directly from `.channel-sidebar .grove-header` on both shells.
Update the helper selector. setupTwoPeers → generateInvite →
openServerSettings was hanging for the full 120s test timeout in
`multi-peer-sync.spec.ts`, `multi-peer-mobile.spec.ts`, and
`permissions.spec.ts` because the dead selector never matched.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The CSP relaxation in setup-e2e gave the WASM bootstrap permission to
run but missed the relay-reachability probe iroh fires on connect:
Refused to connect to 'http://127.0.0.1:3340/ping' because it
violates the document's Content Security Policy directive
"connect-src 'self' ws: wss: https:".
iroh-relay multiplexes its WebSocket and HTTP /ping endpoints onto
the same port. The probe is plain http: in dev (no TLS termination
in front of the local relay), and the production CSP only lists
ws:/wss:/https:. With the probe blocked, iroh marks the relay
unreachable, gossip never establishes neighbors, SyncRequest is
broadcast into the void, and Bob's DAG stays empty — every
multi-peer spec then times out either at the .channel-item wait or
at waitUntilHeadsEqual.
Add `http:` to connect-src in the test-only index.test.html. Source
index.html and the production CSP are unchanged.
Cuts failing specs from 8 → 7 with the remaining set being
slow-bootstrap flakes (first multi-peer test on a cold desktop-chrome
context times out at 30s heads-equal) and the long-standing Firefox
cross-browser case — separate diagnoses, not the same root cause.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
…tart Two related fixes uncovered when the post-CSP run got past the loading screen: 1. The dispatcher in `crates/web/src/test_hooks/dispatcher.rs` buffers events at `window.__willowEventBuffer` whenever `__willowEvent` is briefly absent (the binding registers async from the playwright side, the WASM side is already running). It only auto-drains on its NEXT receive — so for a page that goes quiet between `freshStart` and `peer(page, …)` (e.g. SyncCompleted fires once during join and then nothing), the buffered event sits there forever and `nextEvent` waits on a queue that never fills. `test-hooks.spec.ts:43` was timing out at 5s for exactly this reason. Fix: have the `peer()` factory call `__willowEvent` directly to drain the buffer once, after `exposeBinding` has registered the callback. Subsequent dispatches keep using the built-in per-event drain. 2. `Peer.waitUntilHeadsEqual` defaulted to a 30 s timeout, which covered the warm-relay case (~5–10 s convergence) but blew up on the very first multi-peer assertion in a project. The relay log shows ~30 s of `dial failed: timed out` while iroh-gossip bootstraps the first peer-pair handshake; once a handshake completes the mesh stays warm for subsequent tests. Bump default to 90 s and bump `test-hooks.spec.ts`'s `setTimeout` to 120 s so the helper-level error (with the structured author-key diff) still fires before playwright's per-test ceiling kicks in. Cuts failing specs from 7 → 4 in the most recent run; remaining failures are all the same cold-start tax on tests that ran before this commit's effect propagated, plus the long-standing Firefox cross-browser case. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Mirrors waitUntilHeadsEqual's cold-start budget. With two playwright workers running in parallel, both bootstrap relay handshakes simultaneously and the first peer-pair can take 30-50s before iroh-gossip dials through. 20s was too tight; warm tests still settle in <5s so this is purely a slack-time bump.
`ClientEvent::MessageReceived.channel` carries the internal channel UUID (set by `derive_client_events` from `EventKind::Message::channel_id`), but e2e predicates filter by friendly name (`e.channel === 'dev'`). Resolve UUID to name from the materialized `ServerState` at dispatch time so the wire shape stays test-friendly without changing the public ClientEvent shape consumed by the agent and web crates. Falls back to the raw channel_id when the channel hasn't materialized yet (very rare race during initial sync). Pure test-hooks-only path; no runtime impact on production builds. Fixes failing tests that filter MessageReceived events by named channel: multi-peer-sync.spec.ts:118, multi-peer-mobile.spec.ts:97.
Replace fixed waitForTimeout sleeps with deterministic state-visible
waits in the mobile-shell helpers consumed by the previously failing
tests (multi-peer-sync, multi-peer-mobile, cross-browser-sync):
- switchChannel / createChannel / openServerSettings: close the grove
drawer first if it's open (the overlay covers the bottom tab bar
and silently blocks the home-tab click), then drain push frames
via backSlot waitFor-hidden instead of fixed sleeps.
- openSidebar: drain push frames first so .top-slot-left becomes
the grove glyph rather than a back chevron, then wait for the
drawer's .open class instead of a 500 ms fixed sleep.
- closeSidebar: gate on .open going hidden after the backdrop click.
- sendMessage: closeSidebar() first, then waitFor .mobile-push--channel
visible after the channel-item click.
- generateInvite: wait for the invite-code field to populate via
expect().not.toHaveValue('') and gate Back navigation on the
channel-sidebar / mobile-home returning, dropping two 500 ms sleeps.
- getPeerId fallback: waitFor .peer-id-text visible.
- setupTwoPeers: drop the mobile-only 1500 ms gossip-propagation
sleep — callers that need cross-peer convergence should explicitly
await Peer.waitUntilHeadsEqual() (most already do).
joinViaInvite channel-item timeout bumped 60s → 90s to cover the
slower Firefox iroh bootstrap exercised by cross-browser-sync.
These changes only touch helpers used by the previously failing tests;
the remaining waitForTimeouts in messageAction / editMessage / kickPeer
etc. are scheduled for follow-up migration.
cross-browser-sync.spec.ts: - Test 1 (mobile Chrome → desktop Firefox): replace ad-hoc `.grove-drawer__close, .top-slot-left` composite locator with the closeSidebar helper. The fallback `.top-slot-left` selector reopens the drawer further when `.grove-drawer__close` is missing, hanging the test until the deadline. - Test 2 (mobile Chrome owner sends): drop the openSidebar + click-grove-menu-through-the-drawer sequence (the grove menu button lives in the channel sidebar BEHIND the drawer overlay, so the click was un-actionable). Use openServerSettings which pops back to home and clicks the channel sidebar's grove header directly. - Bump test deadline 120s → 180s; Firefox's iroh bootstrap is measurably slower than Chromium on a cold mesh. multi-peer-sync.spec.ts: - Skip "both peers appear in member list" on mobile-chrome — mobile_shell.rs wires the members action button to `Callback::new(|_| ())`, so there is no right-rail member pane to assert on. Re-enable when Phase 1c surfaces the pane. - Use openMemberList helper instead of clicking `button[aria-label="members"]` directly so the test routes through the channel push on mobile.
Two failures on the Browser tests CI job: 1. phase_2e_search_active_row::active_index_indexes_flat_in_display_order_across_groups was asserting `search-row-b-2` for active_index=3 with a fixture of 2 grove-a + 3 grove-b rows. The flat in-display-order list is `a-1, a-0, b-2, b-1, b-0` (each group ts-desc), so index 3 is actually `b-1`, the second grove-b row. Both the comment and the expected id were internally inconsistent with the fixture from day one — the test never ran on CI before because main couldn't compile crates/web's test binary (wasm-streams duplicate symbol under the leptos 0.7 dep set), so the bug was silent. Update the assertion + comment to match reality. 2. service_worker_bridge::store_and_dispatch_round_trips_through_window_event relied on `take_last_push()` returning the validated payload after `store_and_dispatch` fired the event. That holds only when the test owns the `willow-push` listener. Earlier tests in the same browser session that mount `<App />` (the mobile_ux + persistence groups) install the production listener via `app.rs` with `closure.forget()`, and that listener drains LAST_PUSH ahead of our assertion. Drop the dependency on the post-dispatch slot value and verify only what's still observable in shared state: the event fires + the slot drains cleanly. Playwright E2E: The CI job runs `just test-e2e-full` with the playwright config default (workers=4). Multi-peer + cross-browser specs share a single relay + iroh-gossip mesh; parallel cold-starts race on the relay handshake and produce 30–50 s of dial timeouts that blow past per-spec deadlines. Set PLAYWRIGHT_WORKERS=1 + PLAYWRIGHT_RETRIES=0 to match the verified-passing local config (49 passed, 27 intentional skips, 0 failed). The suite settles in ~8–10 min serially on a fresh runner which fits comfortably under the 30 min job timeout.
intendednull
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Drives the CI pipeline for
claude/fix-ci-387-YGPNafrom a multi-job red wall back to fully green. The work spans three layers — Playwright E2E, wasm-pack browser tests, and the test-hooks WASM dispatcher — plus a CI workflow tweak to run Playwright sequentially.Browser tests (wasm-pack + Firefox)
These tests had never run on
mainbecause the leptos 0.7 dep set caused a duplicate-symbol link error (wasm_streamsdefined twice). Once the leptos 0.8 upgrade further down this branch unblocked compilation, two pre-existing test bugs surfaced:phase_2e_search_active_row::active_index_indexes_flat_in_display_order_across_groups— the fixture lays out 2 grove-a + 3 grove-b rows; sorted by group then ts-desc the flat list isa-1, a-0, b-2, b-1, b-0, soactive_index = 3is the second grove-b row (b-1), not the first. Both the comment and the expected id were inconsistent with the fixture from day one. Fixed assertion + comment to match reality.service_worker_bridge::store_and_dispatch_round_trips_through_window_event— depended ontake_last_push()returning the validated payload afterstore_and_dispatchfired the event. That's only true when the test owns thewillow-pushlistener; earlier tests in the same browser session that mount<App />install the production listener viaapp.rswithclosure.forget(), and that listener drainsLAST_PUSHahead of the assertion. Dropped the post-dispatch slot-value check, kept the still-observable event-fired + drain-edge assertions.Playwright E2E
Several different things were going wrong in parallel:
connect-src; trunk's WASM bootstrap is an inline<script type="module">and iroh probes the relay over plain HTTP. setup-e2e now generatescrates/web/index.test.htmlfromindex.htmlwith'unsafe-inline'appended toscript-srcandhttp:added toconnect-src. Sourceindex.htmland the production CSP are unchanged; thestatic_assets::index_html_declares_content_security_policygate still enforces strict CSP for production.__willow.heads()was returning a JSMap, not an object.serde_wasm_bindgen::to_valueserializesBTreeMap/HashMapasMapinstances by default, soObject.keys(snap.heads)was silently empty andexpect(...).toBeGreaterThan(0)always failed. Switched toSerializer::new().serialize_maps_as_objects(true).MessageReceived.channelcarried the channel UUID, not the name. E2E predicates likee.channel === 'dev'were comparing against a UUID set byderive_client_events. Resolve channel_id → channel name in the test-hooks dispatcher from the materializedServerState(test-hooks-only path; no impact on the agent or production consumers ofClientEvent).window.__willowEventBufferwhenever__willowEventis briefly absent. It only auto-drains on its NEXT receive, so a page that goes quiet betweenfreshStartandpeer(page, …)left buffered events stuck forever. The Peer factory now drains the buffer once afterexposeBindinglands.openServerSettingslooked for.server-gear-btn, which was folded into.channel-sidebar .grove-header. Updated.switchChannel/createChannel/openSidebar/closeSidebar/sendMessage/openServerSettings/generateInvite/getPeerId/setupTwoPeers/openMemberListfrom fixedwaitForTimeoutsleeps towaitFor({ state: 'visible'|'hidden' })on real elements. Also: close the grove drawer before clicking the bottom tab bar (the drawer overlay covers the tabs and silently blocks the click), and drain push frames first inopenSidebarso.top-slot-leftbecomes the grove glyph rather than a back chevron. The remainingwaitForTimeouts in messageAction / editMessage / kickPeer etc. are scheduled for follow-up migration.cross-browser-sync.spec.tshad a.grove-drawer__close, .top-slot-leftcomposite that fell back to.top-slot-left(which OPENS the drawer further) when the dedicated close button was missing, hanging until the deadline. Replaced with thecloseSidebarhelper. Also swappedopenSidebar + click .grove menuforopenServerSettings, since the grove menu lives in the channel sidebar BEHIND the drawer overlay — the click was un-actionable.mobile_shell.rswires the members action button toCallback::new(|_| ()), so there is no right-rail to assert on. Skipped on mobile-chrome with a reference to Phase 1c, matching the precedent inpermissions.spec.ts:239.PLAYWRIGHT_WORKERS=1+PLAYWRIGHT_RETRIES=0in.github/workflows/e2e.ymlto match the verified-passing local config.Result
Local sequential run: 49 passed, 27 intentional skips, 0 failed (
PLAYWRIGHT_WORKERS=1PLAYWRIGHT_RETRIES=0). Browser tests pass all 334 cases. The 27 Playwright skips are intentional cross-project guards (mobile-only on desktop, desktop-only on mobile, cross-browser-sync runs once from desktop-chrome, mobile member-list deferred to Phase 1c).Test plan
wasm-pack test --headless --firefox crates/web— 334 passed, 0 failedWILLOW_FEATURES=test-hooks bash scripts/setup-e2e.sh && PLAYWRIGHT_WORKERS=1 PLAYWRIGHT_RETRIES=0 npx playwright test --project=desktop-chrome --project=mobile-chrome— 49 passed, 27 skipped, 0 failed