hermes - 💡(How to fix) Fix [Bug]: Agent acts on background process completions without checking conversation cancellation state (Telegram)

Summary

When a background process completes and sends a notify_on_complete notification, the agent acts on the result without checking whether the task was cancelled earlier in the conversation thread. This causes the agent to present results the user explicitly said they didn't want.

Steps to Reproduce

1. Start two background processes (e.g. benchmark runs) with notify_on_complete=true
2. User sends a message: "no need to run" — agent acknowledges and kills both processes
3. One or both processes complete before the kill signal lands (exit code 143 = SIGTERM, or the process was already finishing)
4. Gateway delivers [IMPORTANT: Background process proc_xxx completed] notification to the agent
5. Agent presents the results in full, as if the task were still active

Expected Behavior

When a background process completion notification arrives, the agent should check recent conversation context for cancellation signals before acting on the result. If the task was cancelled (user said "no need", "stop", "cancel", or the process was explicitly killed), the agent should:

• Acknowledge the notification silently or with a one-liner ("completed before kill landed — disregarding per your cancellation")
• NOT present results as actionable output

Actual Behavior

Agent presents full results (e.g. benchmark scores, summaries) as if the task were still wanted, ignoring the cancellation that occurred earlier in the same conversation.

Root Cause Hypothesis

Background process completion notifications are injected as new user-turn messages by the gateway. The agent treats them as independent events rather than checking them against the conversation state. There is no mechanism to correlate a notify_on_complete event with a prior cancellation of the same task.

Suggested Fix

When processing a [IMPORTANT: Background process proc_xxx completed] notification:

1. Check recent conversation history for the session_id / process ID referenced in the notification
2. If a cancellation signal exists for that process (kill was issued, user said stop/cancel/no need), suppress the result or deliver a minimal acknowledgment only
3. Alternatively, expose a cancelled_processes set in session state that the agent can check before acting on completion events

Environment

• Platform: Telegram (DM)
• Hermes version: v0.15.1 (2026.5.29)
• Gateway: running as systemd user service on Raspberry Pi
• Trigger: terminal(background=True, notify_on_complete=True) followed by process(action='kill')

Related

This is part of a broader pattern where the agent handles multi-threaded Telegram conversations (reply-to context, background notifications, parallel tool results) as independent events rather than as part of a unified conversation state. The [Replying to: "..."] injection in gateway/run.py (line ~8320) handles the reply-to case correctly at the platform level, but the agent-side reasoning about conversation state across async events is not enforced.