Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix feat(kanban): kanban_create tool should auto-subscribe originating gateway chat to notifications [1 pull requests, 1 comments, 1 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#19479•Fetched 2026-05-05 06:06:30
View on GitHub
Comments
1
Participants
1
Timeline
10
Reactions
0
Author
thesunofdogthesunofdog
Participants
thesunofdogthesunofdog
Timeline (top)
labeled ×4referenced ×3closed ×1commented ×1

Discovered while designing a gateway-first multi-agent workflow where a Telegram user exclusively interacts with an orchestrator profile, which decomposes and dispatches work to specialist profiles via Kanban. The /kanban unblock slash command already supports this pattern on the human side — this fix closes the loop on the agent side.

Root Cause

Discovered while designing a gateway-first multi-agent workflow where a Telegram user exclusively interacts with an orchestrator profile, which decomposes and dispatches work to specialist profiles via Kanban. The /kanban unblock slash command already supports this pattern on the human side — this fix closes the loop on the agent side.

Fix Action

Workaround

Until fixed, the orchestrator can shell out after each kanban_create:

hermes kanban notify-subscribe <task_id> --platform telegram --chat-id <id>

But this requires the orchestrator profile to have terminal toolset access, which is architecturally undesirable for a pure orchestrator role.

PR fix notes

PR #19718: feat(kanban): auto-subscribe gateway chat on tool-driven kanban_create

Description (problem / solution / changelog)

Closes #19479.

Summary

Tool-driven kanban_create (orchestrator agent fan-out from a gateway session) now auto-subscribes the originating chat to the new task's terminal events — at parity with the /kanban create slash command.

Why

A user who exclusively interacts with an orchestrator profile via the gateway (e.g. Telegram) delegates work: the orchestrator decomposes and calls kanban_create for each subtask. Without subscription, when a worker hits an approval gate and calls kanban_block("needs approval"), the user never hears about it — silently breaking the gateway-first multi-agent flow.

Slash-command path (gateway/run.py ~L7088) already does the right thing for /kanban create. Tool path (_handle_create in tools/kanban_tools.py) was a pure DB write with no subscription logic.

Implementation note

The reporter's suggested fix used HERMES_GATEWAY_PLATFORM / HERMES_GATEWAY_CHAT_ID env vars, but those don't exist in the codebase. The real mechanism is contextvars.ContextVar via gateway.session_context.get_session_env() (HERMES_SESSION_* — context-local for asyncio concurrency safety, per the module docstring).

Changes

  • tools/kanban_tools.py: after kb.create_task(...) succeeds, read HERMES_SESSION_PLATFORM / HERMES_SESSION_CHAT_ID / HERMES_SESSION_THREAD_ID / HERMES_SESSION_USER_ID via get_session_env(). When platform + chat_id are both set, call kb.add_notify_sub(...). Best-effort — if gateway.session_context isn't importable (test rigs), log at debug and skip.
  • Response payload gains a subscribed: bool so the orchestrator knows whether terminal events will land back in the originating chat.

Validation

E2E tested with real imports across four cases:

scenariosession varsexpectedactual
classic CLInonesubscribed=false, 0 rows✓
telegram with threadplatform, chat, thread, usersubscribed=true, 1 row with full tuple✓
discord DM (no thread)platform, chatsubscribed=true, thread_id=""✓
partial ctx (chat_id="")platform onlysubscribed=false, 0 rows✓

4 regression tests in tests/tools/test_kanban_tools.py. Full file: 40/40 pass.

Changed files

  • tests/tools/test_kanban_tools.py (modified, +100/-0)
  • tools/kanban_tools.py (modified, +30/-0)

Code Example

# After task creation succeeds:
platform = os.environ.get("HERMES_GATEWAY_PLATFORM")
chat_id = os.environ.get("HERMES_GATEWAY_CHAT_ID")
thread_id = os.environ.get("HERMES_GATEWAY_THREAD_ID")
if platform and chat_id:
    with kb.connect() as conn:
        kb.add_notify_sub(conn, task_id, platform, chat_id, thread_id or "")

---

hermes kanban notify-subscribe <task_id> --platform telegram --chat-id <id>
RAW_BUFFERClick to expand / collapse

Problem

When a human runs /kanban create … as a gateway slash command, the gateway auto-subscribes that (platform, chat_id, thread_id) to terminal Kanban events (gateway/run.py:6936).

When an orchestrator agent calls kanban_create via tool, _handle_create (tools/kanban_tools.py:264–333) performs a pure DB write with no subscription logic. The originating chat never receives blocked/completed/gave_up notifications for tasks the orchestrator created.

Impact

This breaks the gateway-first orchestrator pattern — where a user only interacts with an orchestrator profile via the gateway (e.g. Telegram), and the orchestrator manages the full Kanban board on their behalf.

Without the subscription, the approval gate flow silently fails:

  1. Orchestrator creates task graph via kanban_create
  2. Worker runs, hits an approval gate, calls kanban_block("needs approval")
  3. No notification arrives — chat was never subscribed
  4. User never knows the task is blocked

Note: /kanban unblock <id> already works correctly via gateway slash command — so once the user receives the blocked notification, they can unblock without touching the CLI or dashboard. The missing link is step 3.

Proposed Fix

In _handle_create (tools/kanban_tools.py), after the successful DB write, check if gateway context env vars are set and if so call kb.add_notify_sub(...):

# After task creation succeeds:
platform = os.environ.get("HERMES_GATEWAY_PLATFORM")
chat_id = os.environ.get("HERMES_GATEWAY_CHAT_ID")
thread_id = os.environ.get("HERMES_GATEWAY_THREAD_ID")
if platform and chat_id:
    with kb.connect() as conn:
        kb.add_notify_sub(conn, task_id, platform, chat_id, thread_id or "")

This mirrors what the slash command path does at gateway/run.py:6936. The env vars are already injected by the gateway into all agent sessions.

Workaround

Until fixed, the orchestrator can shell out after each kanban_create:

hermes kanban notify-subscribe <task_id> --platform telegram --chat-id <id>

But this requires the orchestrator profile to have terminal toolset access, which is architecturally undesirable for a pure orchestrator role.

Context

Discovered while designing a gateway-first multi-agent workflow where a Telegram user exclusively interacts with an orchestrator profile, which decomposes and dispatches work to specialist profiles via Kanban. The /kanban unblock slash command already supports this pattern on the human side — this fix closes the loop on the agent side.

extent analysis

TL;DR

The proposed fix involves adding a subscription logic in _handle_create to notify the originating chat of Kanban events after a task is created via the orchestrator agent.

Guidance

  • To fix the issue, add the proposed code snippet in _handle_create (tools/kanban_tools.py) to subscribe the chat to Kanban events after a task is created.
  • Verify the fix by checking if the chat receives blocked/completed/gave_up notifications for tasks created by the orchestrator agent.
  • As a temporary workaround, the orchestrator can use the hermes kanban notify-subscribe command to subscribe to notifications, but this requires terminal toolset access.
  • Ensure the gateway context environment variables (HERMES_GATEWAY_PLATFORM, HERMES_GATEWAY_CHAT_ID, HERMES_GATEWAY_THREAD_ID) are set and injected into the agent sessions.

Example

The proposed code snippet is already provided in the issue:

platform = os.environ.get("HERMES_GATEWAY_PLATFORM")
chat_id = os.environ.get("HERMES_GATEWAY_CHAT_ID")
thread_id = os.environ.get("HERMES_GATEWAY_THREAD_ID")
if platform and chat_id:
    with kb.connect() as conn:
        kb.add_notify_sub(conn, task_id, platform, chat_id, thread_id or "")

Notes

The fix assumes that the gateway context environment variables are correctly set and injected into the agent sessions. If these variables are not set, the subscription logic will not work.

Recommendation

Apply the proposed fix by adding the subscription logic in _handle_create to ensure the chat receives notifications for tasks created by the orchestrator agent. This fix closes the loop on the agent side and supports the gateway-first orchestrator pattern.

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…
#environment variable#network issue#logging issue#authentication issue#prompt issue

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 - ✅(Solved) Fix feat(kanban): kanban_create tool should auto-subscribe originating gateway chat to notifications [1 pull requests, 1 comments, 1 participants]