Skip to content

WS: honor error.UpgradeRequired — a 426 should latch SSE immediately, not burn a retry (codex parity) #427

Description

@justrach

Found while comparing graff's WS→SSE ladder against openai/codex's (deepwiki: their WebsocketStreamOutcome::FallbackToHttp fast-paths an HTTP 426 Upgrade Required straight to sticky HTTP fallback, no retry burn).

graff's ws.zig already distinguishes this case — a non-101 handshake status returns error.UpgradeRequired for 426 specifically, and the error's doc comment says "the caller should fall back to SSE" (ws.zig:52-53, :255-257). But no caller consumes it: UpgradeRequired appears nowhere outside ws.zig, so agent_ws.postLive treats it as a generic handshake failure. Against a server/proxy that has declared it won't upgrade, graff burns one full rebuild + fresh WS dial (which 426s again) before the two-failure latch (ws_failures_before_fallback = 2) finally sets ws_off.

Fix: in the postLive connect-failure handling, catch error.UpgradeRequired and latch ws_off immediately — the server answered authoritatively; a retry can't change its mind. One extra else if on an existing error switch plus a test (the mock in agent_ws_mock.zig can answer 426).

Note: agent_ws.zig sits at 598/600 — this edit must budget a shave (per the slice-1b PR note).

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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions