OpenClaw Discord Delivery Gets Per-Send Custody Checks So Canceled Turns Stop Sending Late Messages
A merged fix closes a Discord delivery-authority gap where canceled, suppressed, or retired replies could still emit later message parts or retry after custody changed — including caption overflow sends and every retry factory.
If you operate OpenClaw on Discord, you may have seen a canceled or suppressed turn still manage to emit a later message part — or a transiently failed post retry itself after the situation that authorized it had ended. A merged repair closes that class of bug at the HTTP boundary.
The two gaps
Delivery authority — whether this reply is still allowed to send — was checked too early and too rarely:
- Memoized first check. Later physical sends, such as media-caption overflow chunks, could reuse a custody decision made before conditions changed.
- Retry outside the fence. Discord’s retry runner could invoke text, media, component, forum-thread, structured poll/sticker, or voice message creates again after cancellation, because the authority check sat outside each retry attempt.
What the fix enforces
Pending-final custody now serializes and revalidates every physical-send admission. The first check accepts durable prepared/queued state and moves custody to unknown immediately before provider I/O; subsequent checks accept only still-current unknown and reject changed authority before any provider request. Every recipient-visible retry factory invokes the authority check inside itself, immediately before its physical request. Media-caption follow-ups forward the same callback, and synthetic session-conflict notices use an explicit no-op fence because they do not own pending-final custody.
Per the merge record, transport regressions run against Discord’s production RequestClient with real loopback HTTP servers: revoking authority after a first media POST blocks caption overflow; a 503 on attempt one plus revocation means attempt two never reaches HTTP (pre-fix code surfaced the 503 instead). Valid multipart replies and legitimate transient retries continue working while custody stays current. No public protocol, config, or Plugin SDK contract changed.
Operator guidance
- Expect fewer “ghost” messages after canceling or suppressing turns; if your incident history includes late retries, this is the fix to cite.
- No config change is required — behavior tightens automatically on update. Multipart replies and transient-failure retries are preserved by design, so silence where messages used to arrive should be investigated rather than accepted as new normal.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF