[Bug]: Session abort after successful tool execution leaves user without confirmation

Bug type

Behavior bug (incorrect output/state without crash)

Summary

When a tool call succeeds but the session is aborted by the provider before the assistant can generate a completion response, the user is left without confirmation. The side effects of the tool (e.g., file edit) are already committed, but the user never hears about them. This creates a "silent success" pattern that confuses users.

Repro Steps

1. User asks agent to edit a config file (e.g., add a model to openclaw.json)
2. Agent reads the file, then calls edit tool
3. Tool returns success: "Successfully replaced 1 block(s) in ~/.openclaw/openclaw.json"
4. Provider aborts the session with AbortError: This operation was aborted
5. Assistant response is never generated or sent
6. User waits indefinitely with no confirmation that the edit succeeded

Evidence

Session transcript (excerpt):

{"type":"message","role":"toolResult","toolName":"edit","content":"Successfully replaced 1 block(s) in ~/.openclaw/openclaw.json"}
{"type":"message","role":"system","customType":"openclaw:prompt-error","content":"This operation was aborted"}
{"type":"message","role":"assistant","errorMessage":"This operation was aborted"}

Result: Edit is committed. User notification is not.

Root Cause

OpenClaw's architecture separates tool execution from response generation:

1. Tool executes → returns result to model
2. Model generates assistant response → sends to user

If the provider aborts between step 1 and 2, the tool's side effects are committed but the user is never notified.

Severity

• User impact: Medium — confusion, frustration, wasted time
• Frequency: Recurring — detected multiple prior AbortError events in cron logs
• Detection difficulty: High — no error surfaced to user

Environment

• openclaw --version: 2026.4.15 (041266a)
• OS: Ubuntu 24.04
• Provider: Ollama (kimi-k2.5:cloud)
• Model: kimi-k2.5:cloud

Workaround

We implemented a cron-based completion notifier that scans pending status files and sends Discord notifications for unconfirmed edits. This is a bandaid — the fix should be at the gateway level.

Proposed Fix

1. Gateway-level retry: If a session aborts after tool success, the gateway should attempt to send a generic "operation completed" message to the user
2. Tool confirmation persistence: Tool results should optionally include a user-facing confirmation that survives session aborts (e.g., a message queue that is flushed to the user channel even if the session dies)
3. Session recovery: After prompt-error: aborted, the session should not get stuck — it should recover and continue processing new messages

Related Issues

• #44610 — Session stops processing after prompt-error: aborted
• #64212 — Image tool fails with "Request was aborted" for NVIDIA Kimi K2.5
• #37505 — Cron job timeout aborts entire model fallback chain via shared AbortController

Labels

bug, bug:behavior, gateway, agents