Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix [Bug]: Background process updates can leak into the wrong Slack thread [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#18101•Fetched 2026-05-01 05:53:49
View on GitHub
Comments
2
Participants
2
Timeline
6
Reactions
0
Author
guglielmofondaguglielmofonda
Participants
alt-glitchalt-glitchguglielmofondaguglielmofonda
Timeline (top)
labeled ×4commented ×2

Root Cause

Suspected Root Cause

Code Example

[Background process proc_6f65d5261750 is still running~ New output:
...process log lines...
]
RAW_BUFFERClick to expand / collapse

Bug Description

Background process progress/output notifications can be delivered into the wrong Slack thread.

I hit this during normal Hermes use in Slack: a background process that had been started from one Slack thread later posted its synthetic progress message into a different Slack thread.

The leaked message looked like this shape:

[Background process proc_6f65d5261750 is still running~ New output:
...process log lines...
]

In this case, the user in the current thread explicitly noticed that the output belonged to another Slack thread.

This is a cross-thread routing leak, not just noisy logging.

Steps to Reproduce

  1. In Slack thread A, start a background process with automatic progress updates enabled (for example via terminal(background=true, check_interval=30) or another path that emits automatic running-process updates).
  2. Leave that process running long enough to produce later output.
  3. In Slack thread B, continue chatting with Hermes.
  4. Wait for the background process from thread A to emit another update.
  5. Observe that the synthetic background-process update can appear in thread B instead of the original thread A.

Expected Behavior

  • Background process updates should be routed only to the original Slack thread/chat/session that started the process.
  • A process started in thread A should never inject progress output into thread B.

Actual Behavior

  • A synthetic background-process update from one Slack thread appeared in a different Slack thread.
  • The injected text included the process session id and raw log lines, making the leak obvious to the user.

Impact

  • Cross-thread leakage of tool/process output between unrelated Slack conversations
  • User confusion and loss of trust
  • Possible exposure of context/logs from one thread into another thread

Environment

  • Platform: Slack
  • Session type: threaded Slack conversations
  • Process pattern involved: automatic background-process progress updates

Related Issues

  • Similar shape to Discord cross-thread watch notification leak: #10411
  • Possibly related to background process notification routing / dedup paths: #15276

Suspected Root Cause

Likely the routing metadata for automatic background-process updates is not being preserved all the way through delivery, and the notification is instead being injected using the currently active event/thread context.

That would mirror the same family of bug as #10411, but for Slack background-process progress output rather than Discord watch-match notifications.

Proposed Fix

  • Store original routing metadata with the background process / notification event (platform, chat_id, thread_id, session key, etc.)
  • Deliver automatic process updates using that stored routing metadata only
  • Add a regression test that starts a process in Slack thread A, sends a normal message in Slack thread B, then verifies the next process update still lands in thread A

extent analysis

TL;DR

Store original routing metadata with the background process and use it to deliver automatic process updates to prevent cross-thread routing leaks.

Guidance

  • Verify that the routing metadata (e.g., platform, chat_id, thread_id, session key) is being correctly stored and retrieved for each background process.
  • Check the notification delivery logic to ensure it uses the stored routing metadata instead of the currently active event/thread context.
  • Implement a regression test as proposed in the issue to validate the fix.
  • Review related issues (#10411 and #15276) to ensure the fix does not introduce similar bugs in other areas.

Example

# Pseudocode example of storing routing metadata with the background process
class BackgroundProcess:
    def __init__(self, platform, chat_id, thread_id, session_key):
        self.routing_metadata = {
            'platform': platform,
            'chat_id': chat_id,
            'thread_id': thread_id,
            'session_key': session_key
        }

    def deliver_update(self, update):
        # Use stored routing metadata to deliver the update
        deliver_notification(self.routing_metadata, update)

Notes

The proposed fix assumes that the routing metadata is not being preserved correctly. If this is not the case, further investigation into the notification delivery logic may be necessary.

Recommendation

Apply the proposed fix by storing original routing metadata with the background process and using it to deliver automatic process updates. This should prevent cross-thread routing leaks and ensure that background process updates are delivered to the correct Slack thread.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#autograd error#model save/load#optimization#mixed precision#training loop

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug]: Background process updates can leak into the wrong Slack thread [2 comments, 2 participants]