Skip to content

Gateway silently drops Slack replies when embedded ACP turn fails (ACP_TURN_FAILED / AcpRuntimeError) #65484

@rijhsinghani

Description

@rijhsinghani

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions