Bug type

Regression / Discord delivery state bug

Summary

On OpenClaw 2026.5.18, Discord progress visible replies can get stuck on a previous failed run. When a later run in the same Discord channel/session succeeds and produces final reply content, Discord can leave the visible message in the old failed state and discard or suppress the new final content.

This looks distinct from a generic model failure: the later run has usable assistant content, but the Discord progress/status delivery state appears to short-circuit because the prior terminal draft/message is still marked failed.

Environment

• OpenClaw: 2026.5.18 (50a2481)
• Channel: Discord guild/channel
• Discord streaming mode: progress
• Account streaming mode: progress
• messages.groupChat.visibleReplies: automatic
• Group policy: allowlist
• Runtime: OpenAI Codex / gpt-5.5 in observed deployment

Steps to reproduce

1. Configure Discord with progress streaming and automatic group visible replies.
2. In a Discord channel/session, trigger a run that fails after creating/updating the visible progress/status message.
3. Send a follow-up message in the same channel/session that should complete normally.
4. Observe the agent/session produces a usable final reply.
5. Observe Discord still shows the previous failed progress/status surface and the successful final reply is not delivered or replaces nothing visible.

Expected behavior

A new run should take ownership of the visible progress surface, or create a fresh delivery surface, even if the prior run ended in failed.

On successful completion, final content should be delivered to Discord regardless of the previous run's failed terminal state.

Actual behavior

The visible Discord state can remain stuck on the prior failed status. The later final reply content is effectively discarded/suppressed from Discord, even though the run has content.

Suspected failure mode

The Discord progress/status draft state is not reset or re-bound at the start of the next run after a terminal failed state. Final delivery may then see the stale failed state and skip replace/send/finalize logic.

The fix likely needs to ensure one of:

• new run start clears/reopens the failed progress message state,
• new run uses a fresh progress message key/surface after terminal failure,
• final delivery never short-circuits solely because a previous run's progress surface is failed.

Related issues

• [Bug]: Discord replies and announce-style deliveries intermittently fail #83638: broad Discord final/announce delivery failures
• Silent delivery drop after overloaded_error recovery #49055: final reply lost after earlier error recovery

This issue is narrower: stale Discord failed progress state persists across runs and blocks a later successful final reply.