hermes - 💡(How to fix) Fix Bug: busy_input_mode: interrupt silently falls back to queue when stream delivery is not confirmed

Description

When busy_input_mode: interrupt is configured, user messages during an active agent run are supposed to interrupt the running task. However, since the stream delivery confirmation logic was added (around d67e602cc and related), interrupts are silently suppressed when the gateway cannot confirm final stream delivery. The user sees no interrupt ack and no error — the previous task runs to completion before the new message is processed.

Reproduction

1. Set busy_input_mode: interrupt in ~/.hermes/config.yaml under display:
2. Start a long-running agent task (e.g., a multi-tool research query via Discord)
3. Send a follow-up message while the agent is still streaming/running
4. Observe: the agent continues the current task to completion, then processes the follow-up

Expected Behavior

The running agent should be interrupted (⚡ Interrupting current task ack) and switch to the new message.

Actual Behavior

Gateway logs show:

Queued follow-up for session agent:main:discord:thread:XXX: final stream delivery not confirmed; sending first response before continuing.

No interrupt ack (⚡) is ever sent. No "Demoting busy_input_mode" log appears (so this is NOT the #30170 subagent protection path). The message is simply queued and processed after the current run finishes.

Frequency

Very high in practice. Our gateway log shows 22 occurrences of "Queued follow-up ... final stream delivery not confirmed" with zero successful interrupts over the same period. The stream delivery confirmation appears to fail consistently on Discord (streaming adapter).

Environment

• Hermes Agent v0.15.1 (2026.5.29)
• Platform: Discord (streaming)
• busy_input_mode: interrupt
• Python 3.11.14

Analysis

The code path in gateway/run.py around line 18296 enters the "queued follow-up" branch when _already_streamed is falsy (final_response_sent, response_previewed, final_content_delivered are all False). This check appears to happen after the interrupt path has already been bypassed — the stream delivery confirmation failure prevents the interrupt from being attempted in the first place.

Related commits:

• d67e602cc — "fix: only suppress gateway replies after confirmed final stream delivery"
• 99d62f6ba — "fix(gateway): protect in-flight subagents from busy-mode interrupts (#30170)"
• 2b16b756a — "fix(gateway): recover model on post-interrupt turn; gate fallback status (#35381)"