openclaw - 💡(How to fix) Fix [Bug]: Parallel tool results can be replaced by synthetic transcript-repair errors, stalling Discord turn [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

During a Discord-hosted agent turn on OpenClaw 2026.4.23, a multi_tool_use.parallel validation step emitted synthetic transcript-repair tool results instead of the actual child tool results:

[openclaw] missing tool result in session history; inserted synthetic error result for transcript repair.

The underlying child exec jobs either continued or completed, but the active assistant turn was interrupted/stalled until the user sent a follow-up message.

Steps to reproduce

The exact timing trigger is unknown, but the observed sequence was:

1. Start a normal Discord channel session.
2. Perform a multi-step tool-heavy task.
3. Call multi_tool_use.parallel with three independent exec validations.
4. Instead of receiving the child tool outputs, the assistant received synthetic transcript-repair results for the parallel tool calls.
5. The user-visible turn stalled until the user asked for status.
6. Polling/verification afterwards showed the underlying work had continued/completed.

Expected behavior

• Parallel tool calls should return their actual child tool results, or concrete per-child timeout/error results.
• Transcript repair should not replace successful/continuing child tool outputs with synthetic missing-result errors.
• If repair is unavoidable, the user-facing turn should still complete with a clean fallback status instead of appearing stalled.

Actual behavior

• The parallel tool wrapper returned synthetic repair errors for each child tool call.
• The assistant did not complete the intended final response in that turn.
• A user follow-up was required to recover the conversation flow.
• Subsequent direct checks showed the underlying commands/work were not necessarily failed; the failure appeared to be in tool-result pairing/delivery rather than the child commands themselves.

OpenClaw version

2026.4.23 (a979721)

Operating system

macOS Darwin 25.2.0 arm64; Node v22.22.1

Install method

npm/global local gateway on macOS

Model

openai-codex/gpt-5.5

Provider / routing chain

Discord -> local OpenClaw gateway/runtime -> openai-codex/gpt-5.5

Logs, screenshots, and evidence

Sanitized observed tool result text:

[openclaw] missing tool result in session history; inserted synthetic error result for transcript repair.

The failed wrapper call shape was equivalent to:

multi_tool_use.parallel([
  exec(validation command A),
  exec(validation command B),
  exec(validation command C)
])

No private repository names, channel IDs, file paths, command contents, or customer data are included here. I can provide more detailed redacted local traces if useful.

Impact and severity

Severity: Medium.

This did not appear to corrupt the session permanently, but it caused a visible reliability break: the agent looked stalled, and the user had to manually ask for status. It is especially confusing because the underlying commands may continue/complete successfully while the tool-result delivery path reports synthetic repair failures.

Additional information

Related but not identical issues found before filing:

• #15008 — closed: intermittent missing tool results in general sessions
• #54776 — open: restart during in-flight tool calls
• #63373 — open: internal transcript content leaked after transcript corruption/repair
• #59060 — open: model-specific/systematic missing tool results with Kimi/EMFILE symptoms

This report is specifically for the current multi_tool_use.parallel / parallel child-tool result path on 2026.4.23 without a gateway restart as the known trigger.