Skip to main content
← Back to list
01Issue
BugOpenSwamp CLI
AssigneesNone

Relationships

#1618 Client shows 'Authentication failed' when actually rate-limited

Opened by stack72 · 8/12/2026

Description

When the server returns HTTP 429 (rate-limited) on a WebSocket upgrade, the client treats it the same as HTTP 401 (unauthorized). The user sees:

Error: Authentication failed — run: swamp auth server-login --server wss://...

This sends the user on a wild goose chase re-logging in, when the real problem is that their IP is temporarily rate-limited. Re-logging in doesn't help because the new token also gets rate-limited.

Root Cause

In remote_run.ts, classifyConnectionError probes the server's /health endpoint. If it returns 200, the client assumes the server is reachable and the problem is auth, producing the misleading "Authentication failed" message. It does not distinguish between 401 (bad credentials) and 429 (rate-limited).

The WebSocket onerror/onclose handlers lose the HTTP status code — by the time the error reaches classifyConnectionError, it's a generic connection failure string with no status code information.

Proposed Fix

  1. Preserve the HTTP status code from the failed WebSocket upgrade so the client can distinguish 401 vs 429 vs other failures
  2. Show a specific message for rate limiting: "Rate-limited by server — retry in {N} seconds" instead of "Authentication failed"
  3. Include a Retry-After header in the server's 429 response so the client knows how long to wait
  4. Do not suggest re-login for non-auth errors — the current message always suggests server-login regardless of the actual failure reason
02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

8/12/2026, 1:46:39 AM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.