Cairn

Feishu/Lark WebSocket disconnect and reconnect handling

NousResearch/hermes-agent · cluster 10616 · gateway

Data as of

9 open items. Fix attempted, not merged.

The short answer

5open issues
4open PRs
17items grouped
Known?
Yes. 17 related items grouped here, 3 issues already closed.
Fix event
No fix has been merged to main. 5 PRs closed without merging; see the attempts below.
Tracker
The maintainers' tracker marks this unresolved. That is separate from the fix event.
Still open
5 issues and 4 PRs.

These issues and fixes center on the Feishu/Lark gateway failing to recover from WebSocket disconnections, including zombie processes, silent failures, and missing in-process reconnect logic. Several fixes address detection of reconnect exhaustion, watchdog supervision of the receive loop, and proper reconnect triggering.

Open issues5

  • Issue#24807gateway/feishu: WS thread exit (ping timeout) is silently swallowed, should trigger in-process reconnect
  • Issue#31367Feishu WebSocket disconnect causes full gateway restart every ~30min
  • Issue#46561Feishu WebSocket does not reconnect after disconnect
  • Issue#53477Feishu gateway: supervise Lark websocket receive-loop and reconnect in-process (1011 keepalive timeout → silently deaf agent)
  • Issue#64712[Bug]: Feishu adapter stuck after Lark SDK WebSocket reconnect exhaustion

Open PRs4

  • PR#10620fix(feishu): terminate process on unrecoverable websocket drops
  • PR#10801fix(feishu): WebSocket watchdog + approval card PATCH + markdown table rendering
  • PR#53508fix(feishu): reconnect when the websocket worker exits after startup
  • PR#95252fix(gateway): treat Feishu/Lark WebSocket close as transient (#67358)

5 PRs closed without merging

From the close comments: done elsewhere 1 · partial fix 1 · superseded by another PR 1 · other 2

  • #24813 fix(gateway/feishu): in-process WS reconnect + fallback send strips thread_id · other
  • #31386 fix(feishu): adapter-level WS reconnect on receive-loop death (#31367) · other → #53508
  • #64741 fix(feishu): detect Lark SDK reconnect exhaustion and trigger reconnection · partial fix → e67ae74, #5500, #31386, #61271, #64741, #73202, #5665, #53508, #31367, #46561, #374151, #64712
  • #67366 fix(gateway): treat Feishu/Lark WebSocket close as transient (#67358) · superseded by another PR → #95252
  • #73202 fix(feishu): notify gateway reconnect watcher on WS thread death · done elsewhere → #73779
Closed issues · 3
  • Closed#10616Feishu/Lark WebSocket drops lead to Zombie Gateway Process without auto-recovery
  • Closed#23491[Bug]: Feishu WebSocket disconnect leaves gateway as zombie process — cron ticker stops, no auto-reconnect
  • Closed#67358[bug] Lark WebSocket disconnect causes gateway process crash
How this cluster was grouped
  • Link evidence (partly structural links): some members are connected by structural evidence (shared changed files, or a closing/superseded reference); the rest are joined by an automated relevance judgement over their text.
  • Members outside that structural core may belong to a different underlying problem.
  • Pairwise link density 0.11: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36. 1.00 means every pair is linked.

Pick up a Lab task

Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.

Open the Lab

At a glance

Subsystem
gateway
Closed issues
3
Attempts
5 PRs closed without merging

For your agent

The same facts, typed.

cluster/10616.json
cluster/10616.md