hermes - 💡(How to fix) Fix bug(dingtalk): session_webhook expires silently within same Stream Mode connection, causing message delivery failures [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#23513Fetched 2026-05-11 03:29:10
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Participants
Timeline (top)
labeled ×4cross-referenced ×1

Root Cause

The session_webhook URL has a TTL set by DingTalk platform. The webhook is only refreshed when a new incoming message arrives (via the callback). The adapter stores it with expired_time_ms, and correctly detects expiration — but the only way to get a fresh webhook is an incoming message. If no one sends a message, the webhook stays expired until a reconnect or a new incoming message.

RAW_BUFFERClick to expand / collapse

Bug Description

When the DingTalk Stream Mode WebSocket connection stays alive for an extended period without any incoming messages, the session_webhook URL can expire before the WebSocket disconnects. The adapter relies on the webhook for replying, but with no new incoming message to refresh it, the bot can receive messages via WebSocket but cannot reply — a silent failure that looks like "DingTalk unresponsive" to end users.

Steps to Reproduce

  1. Start Hermes gateway with DingTalk Stream Mode connected
  2. Let the connection idle for longer than the webhook TTL (varies, observed after hours)
  3. No incoming DingTalk messages during this period
  4. A cron job or proactive message attempts to send to a DingTalk chat
  5. Gateway logs: [Dingtalk] No valid session_webhook for chat_id=xxx
  6. Message delivery silently fails

Root Cause

The session_webhook URL has a TTL set by DingTalk platform. The webhook is only refreshed when a new incoming message arrives (via the callback). The adapter stores it with expired_time_ms, and correctly detects expiration — but the only way to get a fresh webhook is an incoming message. If no one sends a message, the webhook stays expired until a reconnect or a new incoming message.

What We Already Fixed

In _run_stream_client(), we clear session_webhooks on reconnect, so stale webhooks from old connections don't persist. This works when the WebSocket actually disconnects.

What Is Still Broken

When the WebSocket stays connected but the webhook TTL expires, clear() is never called because no reconnect happens. Any send attempt fails silently.

Expected Behavior

  1. (Minimum) The adapter should log a clear warning before the webhook expires
  2. (Better) Proactive webhook refresh via keepalive messages
  3. (Best) Fallback to DingTalk Robot OpenAPI for sending when session_webhook is unavailable

Environment

  • Hermes Agent running on Ubuntu (non-Docker)
  • DingTalk Stream Mode adapter
  • Observed on 2026-05-11

Related

  • #17370 feat(dingtalk): proactive messaging via Robot OpenAPI
  • #14336 feat(dingtalk): proactive messaging via Robot OpenAPI

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