hermes - 💡(How to fix) Fix [Bug]: cron deliver= to plugin platforms (IRC, Teams, Google Chat) fails with 'No live adapter' when run out-of-process

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…

Error Message

delivery error: No live adapter for platform 'irc'. Is the gateway running with this platform connected?

Fix Action

Workaround

Run hermes cron run in the same process tree as hermes gateway so the gateway runner-ref is reachable from cron. Brittle and undocumented; breaks if the gateway crashes or is restarted independently.

Code Example

delivery error: No live adapter for platform 'irc'. Is the gateway running with this platform connected?

---

Job 'cron_<id>': delivery error: No live adapter for platform 'irc'. Is the gateway running with this platform connected?
RAW_BUFFERClick to expand / collapse

Bug Description

Cron jobs that deliver to plugin platforms (IRC, Teams, Google Chat) fail with the error:

delivery error: No live adapter for platform 'irc'. Is the gateway running with this platform connected?

This happens even when the platform is correctly configured and eligible as a cron deliver= target via cron_deliver_env_var (added in #21306). The eligibility check passes; the actual send step has no out-of-process path.

Why this happens

Built-in platforms (Telegram, Discord, Slack, WhatsApp, Signal, Email, SMS, Feishu) ship direct REST helpers in tools/send_message_tool.py (_send_telegram, _send_discord, etc.) so cron can deliver without holding the gateway in the same process. Plugin platforms have only _send_via_adapter (line 426), which requires gateway.run._gateway_runner_ref() to return a live runner. Cron runs as a separate hermes cron run process, so the runner-ref is None and every plugin-platform delivery falls through to the bare error string at line 444.

This is the missing third phase of plugin platform parity:

  • 2e20f6ae2 (Apr 11): "complete plugin platform parity, all 12 integration points" added _send_via_adapter for the in-process path.
  • af9336d57 (May 7): "generic plugin hooks for env enablement + cron delivery" added cron_deliver_env_var so plugin platforms become eligible cron targets.
  • Missing: a way for plugins to register an out-of-process send path so cron in a separate process can actually deliver.

Steps to Reproduce

  1. Configure IRC: IRC_SERVER=irc.libera.chat, IRC_NICKNAME=hermes-bot, IRC_CHANNEL=#test, IRC_HOME_CHANNEL=#test in ~/.hermes/.env.
  2. Start the gateway: hermes gateway in terminal A.
  3. Start cron in a separate process: hermes cron run in terminal B.
  4. Schedule a cron job: hermes cron add --deliver=irc --schedule="*/5 * * * *" --prompt="say hello".
  5. Wait for the job to fire.

Expected Behavior

The message is delivered to #test.

Actual Behavior

Cron logs show:

Job 'cron_<id>': delivery error: No live adapter for platform 'irc'. Is the gateway running with this platform connected?

The cron process has no way to reach the gateway adapter living in the other process. The same shape applies to Teams (deliver=teams) and Google Chat (deliver=google_chat).

Affected Component

  • Gateway (the dispatch site is tools/send_message_tool.py::_send_via_adapter)
  • Cron (the scheduler at cron/scheduler.py:586 calls _send_to_platform from a separate process)

Messaging Platforms

IRC, Microsoft Teams, Google Chat (and any future platform plugin: XMPP #17469, DingTalk #14336, etc.).

Workaround

Run hermes cron run in the same process tree as hermes gateway so the gateway runner-ref is reachable from cron. Brittle and undocumented; breaks if the gateway crashes or is restarted independently.

Proposed Fix

Add an optional standalone_sender_fn field to PlatformEntry so plugins can register an ephemeral send path that opens its own connection, acquires a fresh OAuth token / service-account credential, sends, and closes. The dispatch site in _send_via_adapter falls through to the hook when the gateway runner is unavailable. The hook is optional; existing plugins are unaffected.

I have a PR ready that adds the hook plus reference migrations for IRC (stdlib asyncio), Teams (Bot Framework client_credentials flow), and Google Chat (service-account credentials). PR will be linked below.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING