Symptom
When an embedded ACP turn fails mid-run, the gateway logs the failure but posts no reply back to the originating Slack thread. From a user's perspective the agent goes silent — indistinguishable from "still thinking" or "stuck". Breaks the voice-to-action loop that depends on seeing something back in Slack.
Evidence
From ~/.openclaw/logs/gateway.log on 2026-04-12 at 10:50:47:
[ws] ⇄ res ✗ agent errorCode=UNAVAILABLE errorMessage=AcpRuntimeError: Internal error runId=54aaae90 code=ACP_TURN_FAILED
No downstream Slack message was posted for runId 54aaae90. The originating thread saw only the user's prompt followed by nothing. Next message in that thread came 58 seconds later from a fresh turn the user manually retried.
Impact
- Users cannot distinguish "agent crashed" from "agent working"
- Compounds with config-reload SIGTERM churn (see companion issue on reload debouncing) — a reload kills in-flight embedded runs, ACP fails, user sees silence
- Breaks trust in the voice-to-action pipeline: "Did it work? Should I ask again?"
Suspected code location
Bundled runtime in the published package:
/opt/homebrew/lib/node_modules/openclaw/dist/register.runtime-0ftYpj2n.js
The ACP turn-error path appears to log and return without scheduling a Slack reply on the originating channel/thread.
Recommendation
When an embedded ACP turn fails (ACP_TURN_FAILED, AcpRuntimeError, or any terminal runtime error on an embedded run), post a thread reply to the originating Slack thread of the form:
⚠️ Turn failed: <short reason>
runId: <runId>
Implementation notes:
- Reply target should be captured at run-start (channel + thread_ts stored on the run context)
- Reply should be posted before the run-context is torn down
- If the channel origin is not Slack (e.g. CLI), fall back to emitting a structured error on the response stream
Context
Full debug investigation that surfaced this issue: local artifact at .planning/debug/resolved/ranveer-silent-on-coding-tasks.md in the user's openclaw config repo. Key iteration evidence transcribed above.
Symptom
When an embedded ACP turn fails mid-run, the gateway logs the failure but posts no reply back to the originating Slack thread. From a user's perspective the agent goes silent — indistinguishable from "still thinking" or "stuck". Breaks the voice-to-action loop that depends on seeing something back in Slack.
Evidence
From
~/.openclaw/logs/gateway.logon 2026-04-12 at 10:50:47:No downstream Slack message was posted for runId
54aaae90. The originating thread saw only the user's prompt followed by nothing. Next message in that thread came 58 seconds later from a fresh turn the user manually retried.Impact
Suspected code location
Bundled runtime in the published package:
The ACP turn-error path appears to log and return without scheduling a Slack reply on the originating channel/thread.
Recommendation
When an embedded ACP turn fails (
ACP_TURN_FAILED,AcpRuntimeError, or any terminal runtime error on an embedded run), post a thread reply to the originating Slack thread of the form:Implementation notes:
Context
Full debug investigation that surfaced this issue: local artifact at
.planning/debug/resolved/ranveer-silent-on-coding-tasks.mdin the user's openclaw config repo. Key iteration evidence transcribed above.