feishu channel blocked by stale lark-cli event processes on Hub restart

[AmberCXX]

Summary

After Hub restart (SIGTERM / crash / manual restart), stale lark-cli event +subscribe processes survive the Hub shutdown and continue holding the feishu event WebSocket. When the new Hub instance starts, it detects the stale subscriber and silently skips loading the feishu channel — leaving the user with no feishu connectivity until they manually kill the stale process and restart Hub again.

This has happened 5+ times across multiple days (May 6–10).

Reproduction

1. Hub is running with feishu channel loaded and lark-cli event +subscribe active
2. Hub receives SIGTERM (or is killed)
3. Hub's feishu.stop() is called, but the lark-cli event child process survives (not properly killed)
4. New Hub instance starts
5. Startup check finds the stale lark-cli event process still running → feishu channel skipped

Expected behavior

• Hub shutdown should clean up all child lark-cli processes (especially the event subscriber)
• Channel watchdog should detect and recover from this scenario (e.g., wait for stale process to exit and retry loading)
• OR: Hub should notify the user via an active channel (e.g., wechat) that feishu was skipped

Actual behavior

Feishu channel silently skipped. User only discovers it when they notice no feishu messages are arriving. The log message is buried in stderr with no user-facing notification.

Relevant logs

[2026-05-07 18:54:05] ERROR: 已有 lark-cli event +subscribe 进程在跑 (pid: 3106, 3107)。本次飞书通道启动跳过。
[2026-05-08 11:46:32] ERROR: 已有 lark-cli event +subscribe 进程在跑 (pid: 89457)。本次飞书通道启动跳过。
[2026-05-09 08:59:36] ERROR: 已有 lark-cli event +subscribe 进程在跑 (pid: 4269)。本次飞书通道启动跳过。
[2026-05-10 11:11:05] ERROR: 已有 lark-cli event +subscribe 进程在跑 (pid: 8293)。本次飞书通道启动跳过。

Each time, the fix is: pkill -f 'lark-cli event' + restart Hub.

Environment

• macOS 14.6.1
• Bun 1.3.13
• forge-hub v0.2.0
• lark-cli: installed via npm, auth valid

forge-hub doctor

✓ Bun installed
✓ Hub server runtime
✓ Hub client runtime
✓ LaunchAgent plist
✓ MCP registered
✓ ffmpeg available
✓ lark-cli available
✓ approval_channels configured: [feishu, wechat]
✓ Hub server running (v0.2.0)

Suggested fix

1. In feishu.ts stop(): ensure lark-cli event child process is killed (not just the parent)
2. On startup: if stale subscriber detected, add a retry with backoff (wait for it to exit) instead of skipping permanently
3. Channel watchdog: when channel is skipped (not degraded), notify user via an active channel

[LinekForge]

Fixed in 0058b64.

Root cause: stop() killed the direct lark-cli child process but not its internally forked subprocesses. On Hub restart, stale orphans blocked the new feishu channel from loading — and the old code permanently skipped instead of cleaning up.

Changes (hub-server/channels/feishu.ts + hub-server/channel-loader.ts):

1. start() auto-cleanup: detects stale lark-cli event +subscribe processes via pgrep, kills them (SIGTERM → 2s grace → SIGKILL if needed), then proceeds normally. No more permanent skip.
2. stop() orphan cleanup: after killing the direct child process, runs pkill to catch any forked subprocesses that survived.
3. Skip notification: when any channel is skipped (startup or hot-reload), a system message is pushed to connected instances so the user gets notified through active channels — no more silent failure buried in logs.

The 5+ manual pkill -f 'lark-cli event' cycles should no longer be needed.