Bug Description

On Discord (and any platform where the gateway can deliver an interim/streamed assistant message before the run completes), users can see what looks like a successful reply, and then moments later see the run surface an invalid-final-response failure. The two messages read as a contradiction: the first appears to confirm success, the second says the request failed — with no acknowledgement that the earlier visible message was only intermediate.

Real-world symptom reported on Discord:

• User: "Add 30 dollars to dave receipt for lunch today"
• Bot (visible to user): Added. Dave's at $767.47 now (4/20 lunch, $30).
• Bot shortly after: invalid-final-response failure path, e.g. ❌ Max retries (3) exceeded for invalid responses. Giving up.

Steps to Reproduce

1. Run the gateway on Discord with streaming/preview delivery enabled.
2. Send a prompt that causes the agent to emit a visible interim/streamed reply early in the run (tool result summary, progressive edit, etc.).
3. Force (or encounter) an invalid final response so the agent's retry/fallback path eventually returns {"failed": True} with an empty final_response.
4. Observe that the user sees a first, success-looking visible message, followed shortly by a generic failure string, with no indication the earlier message was intermediate.

Note: this is the exact public-facing sequence observed. Internal retry behaviour upstream of the gateway is not being changed by this report.

Expected Behavior

When a visible interim/streamed reply has already reached the user and the run subsequently fails, the failure message should clearly indicate that the earlier visible message was only an intermediate update — not a completed final answer — so the two messages read coherently instead of contradicting each other.

Actual Behavior

The user sees a first visible message that reads like a successful completion, then a second message from the gateway / agent that reports an invalid-response failure. Nothing in the second message tells the user the earlier visible message was intermediate, so the overall experience reads as "it said it worked, then said it failed."

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

Discord

Operating System

Reported on Discord; reporter's OS not captured at report time.

Python Version

Not captured at report time.

Hermes Version

Not captured at report time; reproducible on current main.

Relevant Logs / Traceback

Indicative strings from the invalid-final-response path (no user log dump was captured):

response.content is empty
⚠️ Max retries (3) for invalid responses — trying fallback...
❌ Max retries (3) exceeded for invalid responses. Giving up.

Root Cause Analysis (optional)

The stream consumer sets already_sent = True as soon as any interim/streamed chunk is delivered to the user. Later, in gateway/run.py _handle_message_with_agent, when agent_result["failed"] is true and final_response is empty, a generic failure string is synthesised (around the "The request failed: {error}" / "⚠️ Session too large..." block). That failure string is then returned to the user without any contextualisation acknowledging that an earlier visible message was only intermediate — producing the contradictory UX.

Retry / validation logic itself (the response.content is empty / max-retries invalid-response handling) is working as intended; the issue is purely the messaging seam at the gateway boundary.

Proposed Fix (optional)

Narrow, messaging-only fix in gateway/run.py: when failed is true and already_sent is true, prefix the final failure text with a short note, e.g.:

Note: the earlier message was an intermediate update, not a completed final answer.

No change to retry logic, no change to when messages are sent, no change to adapters.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR