Test the WebSocket reconnect backoff

[usehoplite]

Problem

The WebSocket store reconnects with backoff, and the root layout calls connect() from an $effect. Before the untrack fix in #136, that combination opened 36 sockets in 5 seconds after a server restart. Nothing in the repository would catch the bug coming back. Greptile asked for this test on #136, but the commit was pushed after #136 was squash-merged, so it did not reach staging/main.

Change

• Fix: a retry called connect() without the allowUnauthenticated flag. Against a --dev server there is no access token, so the retry stopped at "Not authenticated" and the page never reconnected. The store now remembers the mode of the last connect() and the retry reuses it. The first version of these tests missed this because they closed the original socket again and again, and a retry never opened a new one.
• Add websocket.test.ts with five tests. A connect() call from an $effect opens no socket until the retry delay passes. Each retry opens a new socket, and delays double up to the maximum. Retries stop at the configured attempt limit with "Max reconnection attempts reached". Retries keep the connection mode. A successful open resets the delay, and a clean close does not reconnect.
• bun test cannot load .svelte.ts files on its own, so add a small preload (frontend/test/svelte-plugin.js, wired by bunfig.toml) that runs the Svelte compiler on them. bun run test now passes --conditions browser so Svelte loads its client build, where untrack and flushSync work.
• Add @types/bun as a dev dependency (with bun add) so the preload type-checks without a @ts-nocheck.
• Note the preload in AGENTS.md.

The only production change is the retry mode fix, three lines in websocket.svelte.ts.

Verification

• Before the fix, 4 of the 5 reconnect tests failed (the retry must open a new socket). After it, all 9 frontend tests pass. With the untrack line removed, the effect test fails with effect_update_depth_exceeded (checked earlier in Move frontend state to runes and split the browse page #136).
• bun run check, lint, test and build pass, and bun install --frozen-lockfile accepts the lockfile.
• The test fakes WebSocket and setTimeout. It proves retry spacing, the limit and the mode, not a real network drop. The reconnect spacing was checked in a browser in Move frontend state to runes and split the browse page #136. The --dev reconnect itself was not run against a real dev server.

Targets staging/main.

---

Written by anthropic/claude-sonnet-5-5 in the Hoplite agent harness.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
box-box	Ready	Preview	Oct 1, 2026 8:42am UTC

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 23940b9a-e62e-446a-ab2f-e105fe1ed505

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Retries never open new sockets The test starts with connect(true), but each recorded retry calls connect() without that flag. With no access token set, the retry returns before opening a socket. The loop then closes the original fake socket again, so the expected delays can pass without a successful reconnect. The open-and-reset test also opens that stale socket. Set up authentication or preserve the connection mode, and assert that each retry creates a new socket.

Knowledge Base Used: Frontend data and real-time state

[greptile-apps]

Attempt limit remains untested The test stops after eight failed attempts, but the configured limit is ten. It checks that delays stop growing, not that retries stop at the attempt limit. A regression that keeps retrying past that limit would still pass; extend the test through the limit and assert that no further retry is scheduled.

Knowledge Base Used: Frontend data and real-time state