Skip to content

Browser client stops reconnecting after a single HTTP 503 handshake #5699

Description

@brittianwarner

Affected: unmodified npm RivetKit 2.3.13 and 2.3.17 (latest checked 2026-09-11), Chromium 153.0.8010.12, Bun 1.4.0.

Standalone reproduction. After cloning:

bun install --frozen-lockfile --ignore-scripts
bun run browser:install
bun run repro

A loopback test gateway uses real browser WebSockets and a minimal Rivet Init frame:

  1. Establish an SDK connection, then terminate its socket.
  2. Return HTTP 503 once on its next handshake; accept all subsequent handshakes.
  3. The original client emits client/connection_open_failed, becomes idle, and makes no further attempts during a five-second observation window.
  4. A fresh SDK client connects to the same endpoint and actor key while the original remains idle.

Expected: The original connection resumes reconnecting after transient gateway unavailability.

Actual: Recovery stops after the failed handshake. Healthy reconnect succeeds; a persistent HTTP 401 control also becomes idle after one attempt. All six cases are asserted across both versions; exit 0 confirms reproduction.

Browsers expose both 503 and 401 handshake failures as close code 1006, so indiscriminate retries can also retry permanent authentication failures.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions