Bug Report

Summary

Discord component interactions (buttons/selects) stall in the delivery pipeline for 6–12 minutes before being delivered to the agent session, even though Discord acknowledges the interaction correctly and the gateway receives it.

Environment

• OpenClaw: latest (model-agnostic, reproduced with opencode/deepseek-v4-flash-free)
• Channel: Discord (WebSocket mode)
• Config: channels.discord.agentComponents.enabled: true

Steps to Reproduce

1. Send a Discord message with interactive components (buttons/selects)
2. Click a button or select an option
3. Observe that the component interaction is received by the gateway but delivery to the agent session stalls for 6–12 minutes
4. Subsequent interactions on the same component message deliver instantly (~175ms)

Expected Behavior

Component interactions should be delivered to the agent session promptly (within a few seconds, consistent with normal message delivery).

Actual Behavior

• First interaction after any period of inactivity or gateway restart stalls for 6–12 minutes
• Gateway logs show the delivery enters send_attempt_started state but never completes
• The delivery-recovery system eventually finds the stuck entry but refuses blind replay: "Delivery entry {id} delivery state is send_attempt_started; refusing blind replay without adapter reconciliation"
• The interaction eventually arrives at the session after a long delay
• Subsequent interactions on the same message deliver instantly

Evidence

Gateway log excerpt — delivery-recovery refusing to replay stuck entry:

WARN gateway/delivery-recovery Delivery entry {id} delivery state is send_attempt_started; refusing blind replay without adapter reconciliation
WARN gateway/delivery-recovery Retry failed for delivery {id}: delivery state is send_attempt_started; refusing blind replay without adapter reconciliation
INFO gateway/delivery-recovery Delivery recovery complete: 0 recovered, 1 failed

Session-history timestamps confirming consistent delay pattern (all times EEST):

Test 1 (button): 13:59:09 click → 14:05:24 delivery = ~6 min
Test 2 (select): 14:07:29 click → 14:07:29 delivery = ~175ms (instant)
Test 3 (button): 14:14:24 click → 14:26:39 delivery = ~12 min

Analysis

• Not a Discord ACK problem — interaction IS acknowledged (no "This component has expired" error)
• Not a model cold-start — model was warm and actively responding in parallel sessions
• Reproducible across multiple tests — 2 out of 3 interactions stalled
• Second interaction routed instantly (~175ms), suggesting the stall is timing-dependent
• The delivery-recovery system's refusal to replay send_attempt_started entries means no automatic recovery

Root Cause

The component interaction enters the gateway delivery pipeline but gets stuck in send_attempt_started state. The delivery-recovery system detects it ~6 minutes later but refuses retry because the state is mid-flight. The pipeline eventually unblocks without explicit recovery.

This appears to be a gateway delivery pipeline issue — something in the routing of Discord component interaction callbacks through the delivery system causes the send_attempt to hang.

Impact

• Users experience 6–12 minute delays between clicking a component and seeing a response
• Discord shows a yellow triangle (interaction pending) for the duration
• Makes component-based interactive workflows unreliable

Related Issues (not duplicates, but similar area)

• Discord component interaction ACK too slow — causes 'This component has expired' #19909 — Discord component interaction ACK too slow (different: 3s ACK timeout, not delivery pipeline)
• Discord button interactions expire before agent responds #42054 — Discord button interactions expire before agent responds (different: expiry, not delay)
• Discord components v2 buttons: INTERACTION_CREATE not matched by wildcard handler #59885 — Discord components v2 buttons: INTERACTION_CREATE not matched (different: interactions not received at all)
• Discord component callbacks should support asynchronous workflows #90390 — Discord component callbacks should support async workflows (different: TTL defaults)