Problem

When auto-retry handles API errors (overloaded, rate limit, etc.) and the retry succeeds with tool calls (stopReason: 'toolUse'), _resolveRetry() fires on message_end — before tool execution completes. This causes waitForRetry() to resolve early, allowing consumers to proceed with post-prompt cleanup while tools are still in flight.

Impact

This is the root cause of a widely-reported bug in OpenClaw where tool results are intermittently lost, with synthetic errors inserted:

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

Affects ~5-10% of tool calls during API error/retry scenarios. Multiple open issues: openclaw/openclaw#8643, openclaw/openclaw#13351. 15+ PRs attempted symptom-level fixes without identifying this root cause.

Evidence

From a production session:

53ms between tool call and flush. The exec command normally takes 1-5 seconds — the tool never ran.

The Bug

In agent-session.ts, the message_end handler (line ~364):

// BEFORE (fires too early):
if (event.message.role === 'assistant') {
    // ...
    if (assistantMsg.stopReason !== 'error' && this._retryAttempt > 0) {
        this._resolveRetry(); // resolves BEFORE tools execute
    }
}

The message_end event fires when the assistant response arrives, but tool execution (tool_execution_start → tool_execution_end) happens AFTER in the agent loop. So waitForRetry() resolves while tools are still pending.

Fix

Move _resolveRetry() to the agent_end handler, which fires after the full agent loop (including tool execution) completes:

// AFTER (fires at the right time):
if (event.type === 'agent_end' && this._lastAssistantMessage) {
    const assistantMsg = msg as AssistantMessage;
    if (assistantMsg.stopReason !== 'error' && this._retryAttempt > 0) {
        // Resolve AFTER tools have executed
        this._resolveRetry();
        return;
    }
    // ... existing retryable error / compaction checks
}

What changes

• _resolveRetry() now fires on agent_end instead of message_end
• waitForRetry() only resolves after tool execution completes
• No change to retry logic, backoff timing, or error handling
• Backward compatible — consumers already await waitForRetry(), they just get the correct completion signal now

Current workaround

OpenClaw has a workaround in openclaw/openclaw#13746 that calls agent.waitForIdle() before cleanup. This PR is the proper upstream fix that eliminates the need for that workaround.