fix(signaling): answer refused WebSocket upgrades with an HTTP status

[adamshiervani]

Problem

Prod reports almost as many 5xx as 2xx. The API itself is healthy: every HTTP route answers 2xx, 3xx, 401 or 404. The 5xx come from WebSocket upgrades that the signaling handlers refuse by calling socket.destroy() without writing a response. The edge sees the origin close the connection before a status line and records a 504.

Verified against prod with an HTTP/1.1 upgrade request:

Request	Log line	Edge status
Device upgrade with a bad token	[Device] Invalid secret token provided.	504
Client upgrade without a session	[Client] No authentication token.	504

The volume comes from device firmware. It retries the cloud connection every 5 seconds with no backoff and cannot tell a revoked token from a network error, because it never receives a status code. Each device holding a stale token, for example one deleted from the dashboard or re-registered while an old install kept the old token, produces one 504 every 5 seconds until it is reflashed.

Change

• Add rejectUpgrade(socket, status) in src/webrtc-signaling.ts. It writes a minimal HTTP response, ends the socket, and destroys it after the response is flushed, the same sequence ws uses in abortHandshake.
• Use it on every refused upgrade:
  • unknown path: 404
  • device with no token, unknown token, or mismatched device id: 401
  • device reconnecting while a session is in flight: 409
  • client with no session: 401
  • client naming a device it does not own, or that is offline: 404
  • unexpected error in either handler, including a failed database lookup: 500
• authenticateDeviceRequest no longer swallows database errors. Before, a pool timeout or outage during the token lookup returned null, which would now read as a bad token. It propagates to the handler's catch and answers 500, so 401 on the device path means the token itself can never authenticate.
• authenticateClientRequest now returns the status to answer with, so the handler can tell a missing session (401) from a device the user cannot reach (404).

After this ships, the edge reports 401 and 404 for these requests instead of 504.

Follow-up in the firmware

The device side still retries every 5 seconds. runWebsocketClient in kvm/cloud.go should back off exponentially on a 401 from the dial, capped at a few minutes. With this change a 401 means the token is unknown or bound to another device id, and a 5xx means try again later. Backing off rather than clearing the token keeps a device recoverable if the cloud ever answers 401 by mistake.

Tests

test/webrtc-signaling.test.ts starts the router on a real HTTP server and sends upgrade requests with Node's HTTP client. The client rejects when the server closes the socket without a response, so the rejection tests fail on the old code and pass on this change. The happy path checks that a valid device token still completes the upgrade and registers the connection. A failed token lookup is simulated by wrapping the Prisma client, since its model delegates are proxies that vi.spyOn cannot patch.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes WebSocket upgrade auth and error semantics on a production device connection path; misclassified statuses could affect retry behavior until firmware backoff lands.

Overview
Fixes inflated edge 504 rates when WebRTC upgrades are refused: handlers now send a proper HTTP status before closing the socket instead of socket.destroy() with no response.

Adds rejectUpgrade and uses it for unknown paths (404), bad device tokens (401), in-flight conflicts (409), missing client sessions (401), unreachable or unauthorized devices (404), and handler/DB failures (500). Device auth no longer maps Prisma lookup failures to 401—those bubble to 500 so firmware can treat them as transient. Client auth now returns the status to use (401 vs 404) instead of a bare null device id.

New test/webrtc-signaling.test.ts exercises upgrade rejections and a successful device upgrade against a real HTTP server.

^{Reviewed by Cursor Bugbot for commit 1867d90. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 480a8cc. Configure here.}

[cursor]

Upgrade reject can crash process

High Severity

rejectUpgrade calls socket.end on an upgrade socket without an error listener. Node removes its default handler when it emits upgrade, so a failed write such as EPIPE becomes an uncaught exception and can take down the process. That is likely here: stale-token devices retry every 5 seconds and often drop before the status line is flushed.

 

^{Reviewed by Cursor Bugbot for commit 480a8cc. Configure here.}