Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug] Async/subagent completion can be announced before the result payload exists [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#69767•Fetched 2026-04-22 07:48:31
View on GitHub
Comments
2
Participants
3
Timeline
2
Reactions
0
Author
barronlrothbarronlroth
Participants
barronlrothbarronlrothdengluozhangdengluozhangdenisanteater-dotdenisanteater-dot
Timeline (top)
commented ×2

OpenClaw can sometimes announce that an async task or subagent is complete before the actual user-facing result payload is available.

When that happens, the parent session gets a "done" signal without usable output, and the assistant replies with useless fallback text like:

  • "the completion result itself is not included in the visible messages I received"
  • "i can't reliably relay the actual output yet"
  • "i don't see the result attached"

So the bug is not just noisy heartbeat behavior. The deeper issue appears to be that completion is sometimes promoted into the parent session before the result text is durably available there.

Error Message

A child async run finishes, but the parent session receives a completion/update signal before the actual result text is available.

Root Cause

This creates user-visible trust damage because the assistant sounds broken even though the underlying task may actually have completed successfully.

The bad experience is not just transcript noise. It is the assistant being asked to explain a result that has not actually been attached yet.

RAW_BUFFERClick to expand / collapse

[Bug] Async/subagent completion can be announced before the result payload exists

Summary

OpenClaw can sometimes announce that an async task or subagent is complete before the actual user-facing result payload is available.

When that happens, the parent session gets a "done" signal without usable output, and the assistant replies with useless fallback text like:

  • "the completion result itself is not included in the visible messages I received"
  • "i can't reliably relay the actual output yet"
  • "i don't see the result attached"

So the bug is not just noisy heartbeat behavior. The deeper issue appears to be that completion is sometimes promoted into the parent session before the result text is durably available there.

What makes this different from nearby issues

This does not seem identical to the existing related reports:

  • #66648 is about Exec completed notifications leaking into the wrong session
  • #69366 is a UI-layer fix that hides System (untrusted) / HEARTBEAT_OK transcript noise
  • #68464 is the closest one, but it is focused on hardening subagent completion delivery / duplicate delivery / iMessage leakage, not specifically the case where completion is announced before usable payload exists

This issue is specifically about the early completion / missing payload race.

Observed behavior

A child async run finishes, but the parent session receives a completion/update signal before the actual result text is available.

The result is a user-visible assistant message that effectively says:

  • something finished
  • but I can't see the actual output yet

That produces confusing messages instead of either:

  1. the real result, or
  2. silence until the real result exists

Expected behavior

If a completion message is expected, OpenClaw should not announce completion until one of these is true:

  • a usable user-facing reply exists
  • a structured delivery payload exists
  • a sanitized fallback payload exists

If none of those exist yet, the completion should stay deferred and retry later instead of surfacing a placeholder or meta-response.

Suspected source

From local inspection, the likely hot path is the subagent completion announce flow.

Relevant code paths observed:

  • runSubagentAnnounceFlow
  • readSubagentOutput
  • readLatestSubagentOutputWithRetry

The concerning behavior is that the flow appears able to continue even when no usable completion text exists yet, and then still emits an announcement.

In practice, this looks like:

  1. child run finishes
  2. system tries to read child output
  3. output is still missing / not visible yet
  4. completion/update still gets emitted anyway
  5. assistant sees "done" without real payload and sends a hedged nonsense reply

Why this matters

This creates user-visible trust damage because the assistant sounds broken even though the underlying task may actually have completed successfully.

The bad experience is not just transcript noise. It is the assistant being asked to explain a result that has not actually been attached yet.

Suggested fix direction

Fail closed for completion delivery:

  • if completion delivery is expected but no usable payload exists yet, do not announce yet
  • defer / retry until a real payload exists
  • never emit a user-facing completion update with effectively "no output"

Environment

Observed in a Telegram direct-chat setup, but this appears architectural and likely not Telegram-specific.

extent analysis

TL;DR

The most likely fix is to modify the subagent completion announce flow to defer emitting a completion update until a usable payload exists.

Guidance

  • Review the runSubagentAnnounceFlow, readSubagentOutput, and readLatestSubagentOutputWithRetry code paths to ensure they handle cases where no usable completion text exists yet.
  • Consider adding a check to verify the existence of a usable payload before announcing completion, and defer the announcement if the payload is missing.
  • Implement a retry mechanism to periodically check for the availability of the payload and announce completion only when it exists.
  • Ensure that the completion announcement is only emitted when a real payload is available, rather than emitting a placeholder or meta-response.

Example

def runSubagentAnnounceFlow():
    # ...
    payload = readSubagentOutput()
    if payload is None or not is_usable_payload(payload):
        # Defer completion announcement and retry later
        schedule_retry(readLatestSubagentOutputWithRetry)
    else:
        # Emit completion announcement with usable payload
        announce_completion(payload)

Notes

The suggested fix direction is to fail closed for completion delivery, which may introduce additional latency in some cases. However, this approach prioritizes delivering accurate and usable results to the user.

Recommendation

Apply the workaround by modifying the subagent completion announce flow to defer emitting a completion update until a usable payload exists, as this approach addresses the root cause of the issue and ensures a better user experience.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If a completion message is expected, OpenClaw should not announce completion until one of these is true:

  • a usable user-facing reply exists
  • a structured delivery payload exists
  • a sanitized fallback payload exists

If none of those exist yet, the completion should stay deferred and retry later instead of surfacing a placeholder or meta-response.

#environment variable#network issue#logging issue#authentication issue#prompt issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING