fix: prevent duplicate streaming replies on flood control interrupt by konsisumer · Pull Request #8380 · NousResearch/hermes-agent

konsisumer · 2026-04-12T13:35:44Z

Summary

Fixes #8375 — when Telegram flood control interrupts streaming, the response is sent again as a complete duplicate message.

Remove the response_previewed guard from the already_sent check in gateway/run.py at both the main _run_agent return path and the queued-message handling path
Now already_sent alone (set when any content was delivered via streaming) is sufficient to suppress the duplicate send, regardless of whether response_previewed is set

Root cause: The old condition response_previewed and already_sent evaluated to False when flood control interrupted streaming because response_previewed was not set in that code path, even though already_sent was True (partial content had been delivered). This caused _process_message_background in base.py to re-send the full response.

Test plan

Existing stream consumer tests continue to pass (already_sent / final_response_sent semantics unchanged)
The fix is a net deletion of guard logic — the three scenarios from the issue's test matrix are covered:
- Normal completion: final_response_sent=True → suppressed (unchanged)
- Flood interrupt: already_sent=True, response_previewed=False → now correctly suppressed
- No content sent: already_sent=False → not suppressed (unchanged)

…ousResearch#8375) When Telegram flood control interrupts streaming, final_response_sent stays False but already_sent is True (partial content was delivered). The old condition required response_previewed AND already_sent, which evaluated to False in this path, so the response was sent again as a complete duplicate. Remove the response_previewed guard so that already_sent alone is sufficient to suppress the duplicate send. This matches the semantic intent: if any content was already delivered via streaming, don't re-send the full response. Fixed in both the main _run_agent return path and the queued-message handling path. Closes NousResearch#8375

The previous fix removed the response_previewed guard entirely, causing interim commentary to incorrectly suppress final response delivery. Add a stream_content_sent flag that distinguishes actual streaming content from commentary, so flood-control duplicates are still prevented without breaking interim commentary delivery.

The test_real_interrupt_subagent test creates a parent AIAgent via __new__ (skipping __init__) but omits _execution_thread_id, which was added in a recent commit. parent.interrupt() crashes with AttributeError, leaving a daemon thread's class-level patch on AIAgent._build_system_prompt active — contaminating TestBuildSystemPrompt and TestToolUseEnforcementConfig tests on the same xdist worker.

…st contamination AIAgent quiet_mode sets tools/run_agent/etc loggers to ERROR. When another test triggers that code path in the same xdist worker, test_agent_log_still_receives_all fails because the tools logger suppresses INFO records. Reset these loggers to NOTSET before each test.

Set CODEX_HOME to a nonexistent tmp dir so load_pool() cannot import credentials from ~/.codex/auth.json during test runs.

The test created a new _FakeChatCompletions per _FakeClient, but run_agent creates a fresh OpenAI client for each API request. This reset the call counter so the second request also returned a tool call instead of the "done" response, exhausting max_iterations. Additionally, the agent always prefers the streaming path, but the fake client returned a SimpleNamespace (not iterable), causing a fallback to non-streaming — which consumed an extra call and further confused the counter. Fix both by: 1. Sharing a single _FakeChatCompletions across all _FakeClient instances 2. Returning streaming chunk iterators instead of SimpleNamespace responses 3. Adding close() and _client.is_closed to satisfy client lifecycle checks

…rol-8375' into HEAD

…generators The test set agent._disable_streaming = True but returned generator- based streaming chunks from the fake client. When _disable_streaming redirects to the non-streaming _interruptible_api_call path, it receives a generator (no .choices attribute) and fails with "vars() argument must have __dict__ attribute" in the response validation error handler. Remove the flag so the streaming path processes the chunk generators directly, which is what they were designed for.

- auth_provider_gate: clear ANTHROPIC_API_KEY/ANTHROPIC_TOKEN so CI env vars don't make is_provider_explicitly_configured return True - session_env: clear HERMES_SESSION_KEY so os.environ fallback in get_session_env doesn't pick up stale values from parallel xdist workers

Multiple hermes IDs (kimi-coding, kimi-coding-cn) map to the same models.dev ID (kimi-for-coding). The dict comprehension {v:k} picked the last writer, resolving kimi-for-coding → kimi-coding-cn instead of kimi-coding. Use setdefault to keep first-inserted (primary) ID. Also add KIMI_API_KEY to the kimi-for-coding overlay's extra_env_vars for direct credential detection, and mock fetch_models_dev in overlay slug tests to prevent flaky CI failures from network/cache state.

…github.com/konsisumer/hermes-agent into HEAD

…lood control Three fixes for the duplicate reply bug affecting all gateway platforms: 1. base.py: Suppress stale response when the session was interrupted by a new message that hasn't been consumed yet. Checks both interrupt_event and _pending_messages to avoid false positives. (#8221, #2483) 2. run.py (return path): Remove response_previewed guard from already_sent check. Stream consumer's already_sent alone is authoritative — if content was delivered via streaming, the duplicate send must be suppressed regardless of the agent's response_previewed flag. (#8375) 3. run.py (queued-message path): Same fix — already_sent without response_previewed now correctly marks the first response as already streamed, preventing re-send before processing the queued message. The response_previewed field is still produced by the agent (run_agent.py) but is no longer required as a gate for duplicate suppression. The stream consumer's already_sent flag is the delivery-level truth about what the user actually saw. Concepts from PR #8380 (konsisumer). Closes #8375, #8221, #2483.

teknium1 · 2026-04-15T10:42:33Z

Merged via PR #10235. Your stream_content_sent concept informed the fix — we simplified by removing the response_previewed gate entirely (already_sent alone is authoritative). The fix also adds defense-in-depth in base.py for the interrupt race (#8221/#2483). Thanks @konsisumer!

…kflow (#10242) * fix(gateway): suppress duplicate replies on interrupt and streaming flood control Three fixes for the duplicate reply bug affecting all gateway platforms: 1. base.py: Suppress stale response when the session was interrupted by a new message that hasn't been consumed yet. Checks both interrupt_event and _pending_messages to avoid false positives. (#8221, #2483) 2. run.py (return path): Remove response_previewed guard from already_sent check. Stream consumer's already_sent alone is authoritative — if content was delivered via streaming, the duplicate send must be suppressed regardless of the agent's response_previewed flag. (#8375) 3. run.py (queued-message path): Same fix — already_sent without response_previewed now correctly marks the first response as already streamed, preventing re-send before processing the queued message. The response_previewed field is still produced by the agent (run_agent.py) but is no longer required as a gate for duplicate suppression. The stream consumer's already_sent flag is the delivery-level truth about what the user actually saw. Concepts from PR #8380 (konsisumer). Closes #8375, #8221, #2483. * fix(cron): include job_id in delivery and guide models on removal workflow Users reported cron reminders keep firing after asking the agent to stop. Root cause: the conversational agent didn't know the job_id (not in delivery) and models don't reliably do the list→remove two-step without guidance. 1. Include job_id in the cron delivery wrapper so users and agents can reference it when requesting removal. 2. Replace confusing footer ('The agent cannot see this message') with actionable guidance ('To stop or manage this job, send me a new message'). 3. Add explicit list→remove guidance in the cronjob tool schema so models know to list first and never guess job IDs.

…lood control Three fixes for the duplicate reply bug affecting all gateway platforms: 1. base.py: Suppress stale response when the session was interrupted by a new message that hasn't been consumed yet. Checks both interrupt_event and _pending_messages to avoid false positives. (NousResearch#8221, NousResearch#2483) 2. run.py (return path): Remove response_previewed guard from already_sent check. Stream consumer's already_sent alone is authoritative — if content was delivered via streaming, the duplicate send must be suppressed regardless of the agent's response_previewed flag. (NousResearch#8375) 3. run.py (queued-message path): Same fix — already_sent without response_previewed now correctly marks the first response as already streamed, preventing re-send before processing the queued message. The response_previewed field is still produced by the agent (run_agent.py) but is no longer required as a gate for duplicate suppression. The stream consumer's already_sent flag is the delivery-level truth about what the user actually saw. Concepts from PR NousResearch#8380 (konsisumer). Closes NousResearch#8375, NousResearch#8221, NousResearch#2483.

…kflow (NousResearch#10242) * fix(gateway): suppress duplicate replies on interrupt and streaming flood control Three fixes for the duplicate reply bug affecting all gateway platforms: 1. base.py: Suppress stale response when the session was interrupted by a new message that hasn't been consumed yet. Checks both interrupt_event and _pending_messages to avoid false positives. (NousResearch#8221, NousResearch#2483) 2. run.py (return path): Remove response_previewed guard from already_sent check. Stream consumer's already_sent alone is authoritative — if content was delivered via streaming, the duplicate send must be suppressed regardless of the agent's response_previewed flag. (NousResearch#8375) 3. run.py (queued-message path): Same fix — already_sent without response_previewed now correctly marks the first response as already streamed, preventing re-send before processing the queued message. The response_previewed field is still produced by the agent (run_agent.py) but is no longer required as a gate for duplicate suppression. The stream consumer's already_sent flag is the delivery-level truth about what the user actually saw. Concepts from PR NousResearch#8380 (konsisumer). Closes NousResearch#8375, NousResearch#8221, NousResearch#2483. * fix(cron): include job_id in delivery and guide models on removal workflow Users reported cron reminders keep firing after asking the agent to stop. Root cause: the conversational agent didn't know the job_id (not in delivery) and models don't reliably do the list→remove two-step without guidance. 1. Include job_id in the cron delivery wrapper so users and agents can reference it when requesting removal. 2. Replace confusing footer ('The agent cannot see this message') with actionable guidance ('To stop or manage this job, send me a new message'). 3. Add explicit list→remove guidance in the cronjob tool schema so models know to list first and never guess job IDs.