gateway keeps restarting
✅Solved
Root Cause: Anthropic API Streaming Hangs + No Socket-Level Timeout
The amplifier: No abort signal/timeout on runTurn()
The missing signal at line 22509 of reply-DhtejUNZ.js is what turns a temporary API hiccup into a permanent session blockage. The for await loop at line 3042 waits forever. With
a proper timeout, the session would error out, recover, and be ready for the next message.
The session isn't hanging because of a bug in OpenClaw's queue logic per se. Here's what actually happens every time:
Timeline (both times):
1. You send a DM → bot enters processing
2. memory-lancedb: recall failed — @lancedb/lancedb module is missing (57 failures today). Processing continues without memory.
3. runtime.runTurn() starts → makes streaming API call to Anthropic at 160.79.104.10:443
4. The TCP connection establishes successfully
5. The Anthropic API streaming response stalls — the connection stays ESTABLISHED with 0 bytes in the send queue, but no SSE events arrive
6. The for await (const event of runtime.runTurn(...)) loop at reply-DhtejUNZ.js:3042 blocks forever
7. No abort signal, no socket timeout, no read timeout → infinite hang
8. The KeyedAsyncQueue blocks all subsequent messages for this session
Why the timeoutSeconds settings don't help:
- channels.telegram.timeoutSeconds: 30 — this is for Telegram API calls (sending messages), not model calls
- agents.defaults.timeoutSeconds: 900 — this configures the agent timeout but is never passed as a signal to runTurn() in the dispatch path (line 22509)
Is this a bug?
The amplifier: No abort signal/timeout on runTurn()
The missing signal at line 22509 of reply-DhtejUNZ.js is what turns a temporary API hiccup into a permanent session blockage. The for await loop at line 3042 waits forever. With
a proper timeout, the session would error out, recover, and be ready for the next message.
The session isn't hanging because of a bug in OpenClaw's queue logic per se. Here's what actually happens every time:
Timeline (both times):
1. You send a DM → bot enters processing
2. memory-lancedb: recall failed — @lancedb/lancedb module is missing (57 failures today). Processing continues without memory.
3. runtime.runTurn() starts → makes streaming API call to Anthropic at 160.79.104.10:443
4. The TCP connection establishes successfully
5. The Anthropic API streaming response stalls — the connection stays ESTABLISHED with 0 bytes in the send queue, but no SSE events arrive
6. The for await (const event of runtime.runTurn(...)) loop at reply-DhtejUNZ.js:3042 blocks forever
7. No abort signal, no socket timeout, no read timeout → infinite hang
8. The KeyedAsyncQueue blocks all subsequent messages for this session
Why the timeoutSeconds settings don't help:
- channels.telegram.timeoutSeconds: 30 — this is for Telegram API calls (sending messages), not model calls
- agents.defaults.timeoutSeconds: 900 — this configures the agent timeout but is never passed as a signal to runTurn() in the dispatch path (line 22509)
Is this a bug?
Solution
Yeah — what you’ve described is a real bug / missing safeguard.
Two separate (but compounding) things are going on:
1) No abort/timeout wired into ACP dispatch
- In the ACP auto-reply path,
-
So your conclusion is correct:
2) Missing streaming inactivity timeout (known class of issue)
Even when an absolute timeout exists, there’s also the broader problem of “connection stays open, no chunks arrive”. There’s already a tracked issue for that pattern:
https://github.com/openclaw/openclaw/issues/17258
- Also drop your
Two separate (but compounding) things are going on:
1) No abort/timeout wired into ACP dispatch
- In the ACP auto-reply path,
tryDispatchAcpReply()acpManager.runTurn({ ... })signalsrc/auto-reply/reply/dispatch-acp.ts-
AcpRunTurnInputsignalruntime.runTurn(...)for await (...)So your conclusion is correct:
agents.defaults.timeoutSecondsAbortSignal2) Missing streaming inactivity timeout (known class of issue)
Even when an absolute timeout exists, there’s also the broader problem of “connection stays open, no chunks arrive”. There’s already a tracked issue for that pattern:
https://github.com/openclaw/openclaw/issues/17258
What to do next
- If you haven’t already, please file a GitHub issue (or comment on #17258) with your specific finding: ACP dispatch not passing a signal + the exact stall behavior. That’s actionable and should be fixable by plumbing a timeout-backedAbortSignalacpManager.runTurn(...)- Also drop your
openclaw --version
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
134,426Members
Resources
Was this page helpful?
