Stop reconnecting after backend disconnects

[pierremtb]

Closes #13163.

What

• classify only the current legacy backend-disconnect response as a terminal engine connection error
• tear down that connection immediately and route the terminal error through the existing websocket-close path
• stop both established auto-reconnect and the initial connection retry loop
• show manual reconnect UI instead of retrying indefinitely
• keep all other legacy failures on their existing paths, including the common pre-header auth_token_missing response

Why

This is intentionally the smallest deployable compatibility change for today's untyped backend-disconnect response. It introduces the shared terminal-error plumbing but no broader error taxonomy or new API response types. #13328 is stacked on this PR and replaces the legacy message match with the typed protocol.

How to test

1. Open the Vercel preview and open a project until the engine stream is working.
2. Open DevTools → Network
3. In DevTools → Console, run:

const ws = window.engineCommandManager.connection?.websocket

if (!ws || ws.readyState !== WebSocket.OPEN) {
  throw new Error("Engine WebSocket is not open")
}

ws.dispatchEvent(
  new MessageEvent("message", {
    data: JSON.stringify({
      success: false,
      request_id: "manual-backend-disconnect-test",
      errors: [
        {
          error_code: "internal_api",
          message:
            "modeling connection interrupted; please reconnect and retry",
        },
      ],
    }),
  })
)

Expected behavior:

• The stream disconnects immediately.
• The “Failed to connect” screen appears with a Reconnect button.
• No new engine WebSocket is created automatically.

[vercel]

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

Project	Deployment	Actions	Updated
modeling-app	Ready	Preview	Sep 9, 2026 12:28pm UTC

[pierremtb]

This is where we reuse the detection introduced for client error reporting to prevent further reconnect attempts.

[pierremtb]

I have upcoming work at #13328, https://github.com/KittyCAD/api/pull/4472, and KittyCAD/modeling-api#1340 to get proper error types and use that instead of the string parsing.

[andrewvarga]

A small edge case I haven't reproduced: the idle callback still seems to be activated when the backend disconnects, so this can happen:

• backend disconnects due to an error
• idle timeout completes after 1 minute
• move your mouse -> new connection is started

I'm thinking if we're on the disconnection page, the idle state shouldn't be triggered ideally, but a simpler fix is to guard all automatic reconnections with something like:

if (engineCommandManager.lastConnectionError?.terminal) return

It doesn't feel like a big issue though.

[andrewvarga]

Confirmed my finding is fixed!