Description

When an Anthropic overloaded_error occurs on the first LLM attempt but the session recovers on retry and produces a valid response (stop=stop), the Discord message delivery silently fails. The response is recorded in the session transcript but never sent to Discord.

Reproduction

1. A thread-bound session receives a user message
2. First Anthropic API call returns overloaded_error
3. Session retries and succeeds — tools are called, response is generated
4. Final assistant message has stopReason: stop (clean completion)
5. Message never appears on Discord — no error logged

Evidence

Observed 3 times on 2026-03-17:

• Morning Marketing cron (5:20 AM COT): status: ok, deliveryStatus: not-delivered
• Morning Marketing retry (5:57 AM COT): same pattern
• Thread-bound email session (9:00 AM COT): reply in transcript at 14:01:31 UTC, never delivered to Discord

All share the pattern: overloaded_error on first attempt → recovery → valid response → delivery drops.

Expected behavior

If the LLM session recovers and produces a valid response, the delivery layer should still send it to Discord regardless of earlier errors in the session.

Environment

• OpenClaw version: 2026.3.13
• Provider: Anthropic (claude-sonnet-4-6)
• Channel: Discord
• Session types: cron (isolated) and thread-bound

Workaround

Reduced auth.cooldowns.billingBackoffHoursByProvider.anthropic from 0.25h to 0.001h to prevent cascading failures.