Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
When a WebSocket connection fails, the log only shows handshake-timeout or closed before connect. There is no indication of which phase stalled — TCP accept, WS upgrade, auth validation, session attach, or subscription registration. This makes it impossible to distinguish a network issue from an auth failure from a session manager deadlock.
Steps to reproduce
- Start gateway
- Trigger or observe a handshake-timeout in gateway/ws logs
- Note: only the final outcome is logged, not the phase where it stalled
Expected behavior
ateway should emit a phase log per connection on failure showing the last completed phase:
tcp accepted → ws upgrade started → auth token received → auth validated → session attached → subscriptions registered → ready
Actual behavior
When a WebSocket connection fails, the log only shows handshake-timeout or closed before connect. There is no indication of which phase stalled — TCP accept, WS upgrade, auth validation, session attach, or subscription registration. This makes it impossible to distinguish a network issue from an auth failure from a session manager deadlock.
OpenClaw version
2026.4.15
Operating system
Windows 11 (10.0.26200, x64)
Install method
npm global
Model
N/A
Provider / routing chain
openclaw → openai (not applicable — gateway-level issue)
Additional provider/model setup details
Details (paste into the free-text box):
Default route is openclaw → openai (direct API key auth).
Fallback chain: openai/gpt-5.4 → anthropic/claude-sonnet-4-6 → anthropic/claude-opus-4-7.
No cloudflare-ai-gateway or openrouter in this setup.
Auth profiles configured under auth.profiles.openai:default (mode: api_key).
Config lives in ~/.openclaw/openclaw.json under agents.defaults.model and plugins.entries.
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
When a WebSocket connection fails, the log only shows handshake-timeout or closed before connect. There is no indication of which phase stalled — TCP accept, WS upgrade, auth validation, session attach, or subscription registration. This makes it impossible to distinguish a network issue from an auth failure from a session manager deadlock.
Steps to reproduce
Expected behavior
ateway should emit a phase log per connection on failure showing the last completed phase:
tcp accepted → ws upgrade started → auth token received → auth validated → session attached → subscriptions registered → ready
Actual behavior
When a WebSocket connection fails, the log only shows handshake-timeout or closed before connect. There is no indication of which phase stalled — TCP accept, WS upgrade, auth validation, session attach, or subscription registration. This makes it impossible to distinguish a network issue from an auth failure from a session manager deadlock.
OpenClaw version
2026.4.15
Operating system
Windows 11 (10.0.26200, x64)
Install method
npm global
Model
N/A
Provider / routing chain
openclaw → openai (not applicable — gateway-level issue)
Additional provider/model setup details
Details (paste into the free-text box):
Default route is openclaw → openai (direct API key auth).
Fallback chain: openai/gpt-5.4 → anthropic/claude-sonnet-4-6 → anthropic/claude-opus-4-7.
No cloudflare-ai-gateway or openrouter in this setup.
Auth profiles configured under auth.profiles.openai:default (mode: api_key).
Config lives in ~/.openclaw/openclaw.json under agents.defaults.model and plugins.entries.
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response