Skip to content

fix: bound solver WebSocket startup - #242

Open
Kewe63 wants to merge 1 commit into
t1protocol:canaryfrom
Kewe63:fix/241-bound-websocket-startup
Open

Kewe63 wants to merge 1 commit into
t1protocol:canaryfrom
Kewe63:fix/241-bound-websocket-startup

Conversation

@Kewe63

@Kewe63 Kewe63 commented Sep 19, 2026

Copy link
Copy Markdown

Description

  • Replace the startup busy-wait with an event-driven WebSocket open waiter.
  • Reject startup on error, close before opening, or a bounded five-second timeout.
  • Remove temporary startup listeners and clear the timer on every outcome.
  • Close and clear the failed socket without clearing a newer socket instance.
  • Add deterministic regression coverage for open, close-before-open, error, and timeout paths.

Motivation and Context

SolverWebSocketClient.start() previously polled until readyState equaled OPEN. When a server rejected the WebSocket upgrade, the socket transitioned to CLOSED; because that terminal state could never equal OPEN, the startup promise remained pending forever and the solver bot could not reach its normal error handling or cleanup.

The new waiter resolves only on open and rejects all terminal or bounded-failure paths. The existing stop() lifecycle remains unchanged so this PR stays focused on startup.

Fixes #241.

How Has This Been Tested?

  • Loopback reproduction on current canary:
    • Accepted WebSocket upgrade — resolved, exit 0.
    • HTTP 503 handshake rejection — remained pending past the bound, exit 1.
  • Pre-fix focused regression — 1 passed, 2 failed; close-before-open and timeout both lost the test deadline.
  • bun test test/SolverWebSocketClient.test.ts — 5 passed, 0 failed after the fix, including retry after failed startup.
  • Full package suite after the fix — 6 passed, 3 failed. The three failures are unchanged baseline failures recorded by the audit: two stale price fixtures raise Invalid argument type in ToBigInt operation, and processIntentLogs.test.ts checks an asynchronous notification before it occurs.
  • Project TypeScript checking remains blocked by unchanged baseline errors in ViemIntentObserver.ts, Websocket.integration.test.ts, and processIntentLogs.test.ts. Isolated checking also exposes the existing Bun-specific WebSocket constructor headers overload, which predates this change.
  • git diff --check — passed.
  • Independent code review — passed with no blocking findings; its retry-after-failure coverage suggestion was applied.

Types of changes (remove all unchecked types)

  • Bug fix (non-breaking change which fixes an issue)

Checklist:

  • I assessed the documentation impact; no documentation update is required.
  • I assessed the deployment-script impact; no deployment-script update is required.
  • I added focused regression coverage for all startup outcomes.

Reject solver startup on close, error, or timeout and clean stale socket state so callers can recover.\n\nFixes t1protocol#241.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Rejected WebSocket handshakes leave SolverWebSocketClient.start pending

1 participant