Bug Description

Background-process watch notifications can be injected into whichever threaded session happens to be active when the gateway drains the global watch queue.

That means a watch hit from one topic can appear in another unrelated topic. Once that happens, the synthetic system message also pollutes the wrong session transcript.

Steps to Reproduce

1. Start a background process with watch_patterns or notify_on_complete from topic/thread A
2. Before it finishes, send a message in topic/thread B
3. Let the watched process emit a match or completion while topic B is active
4. Observe the synthetic background-process notification arrive in topic B instead of topic A

Expected Behavior

Watch notifications should route back to the session/thread that started the background process.

Actual Behavior

The gateway can inject the notification into the currently active thread, causing cross-topic bleed-through and wrong transcript history.

Affected Component

Gateway (background process notifications / threaded session routing)

Messaging Platform (if gateway-related)

Telegram

Likely affects any threaded gateway path using the same queue-drain logic.

Root Cause Analysis (optional)

Watch events are placed on a global completion queue. When the gateway drains that queue after an agent turn, it injects the notification using the current event source instead of the originating process/session routing metadata.

Because watch_match / watch_disabled events do not carry platform/chat/thread/user routing information, a notification from one topic can be delivered into another active topic.

Proposed Fix (optional)

Include platform/chat/thread/user metadata on queued watch events and rebuild the synthetic event from that metadata when injecting.

If routing metadata is missing, drop the notification instead of delivering it to an unrelated session.

Are you willing to submit a PR for this?

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