[BUG] Connected to QQ and DingTalk, kept online overnight, PANIC and exited.

[atom12138]

[Info] 2026-03-02 06:26:18 client.go:244:listenMessageAndHandle [ws][ID:][Shard:(0/1)][Intent:33554432] message queue is closed
[Info] 2026-03-02 06:26:20 client.go:64:Connect [ws][ID:][Shard:(0/1)][Intent:33554432], url wss://api.sgroup.qq.com/websocket, connected
[Info] 2026-03-02 06:26:20 client.go:128:Write [ws][ID:][Shard:(0/1)][Intent:33554432] write Identity message, {"op":2,"d":{"token":"QQBot ACVM177qmAnQ-DzWgisBzlL0awx6-eti52kJLOV7P9zxccEa","intents":33554432,"shard":[0,1],"properties":{}},"Session":null}
[Info] 2026-03-02 06:26:20 client.go:214:readMessageToQueue [ws][ID:][Shard:(0/1)][Intent:33554432] receive Hello message, {"d":{"heartbeat_interval":41250},"op":10}
[Info] 2026-03-02 06:26:20 client.go:214:readMessageToQueue [ws][ID:][Shard:(0/1)][Intent:33554432] receive InvalidSession message, {"op":9,"d":false}
[Error] 2026-03-02 06:26:20 client.go:92:Listening [ws][ID:][Shard:(0/1)][Intent:33554432] Listening stop. err is code:9005, text:invalid session, traceID:
[Error] 2026-03-02 06:26:20 client.go:198:readMessageToQueue [ws][ID:][Shard:(0/1)][Intent:33554432] read message failed, websocket: close 4924: session ip forbidden, message
[Info] 2026-03-02 06:26:20 client.go:244:listenMessageAndHandle [ws][ID:][Shard:(0/1)][Intent:33554432] message queue is closed
[Error] 2026-03-02 06:26:20 local.go:91:newConnect [ws/session] Listening err code:9005, text:invalid session, traceID:
[Info] 2026-03-02 06:26:22 client.go:64:Connect [ws][ID:][Shard:(0/1)][Intent:33554432], url wss://api.sgroup.qq.com/websocket, connected
[Info] 2026-03-02 06:26:22 client.go:128:Write [ws][ID:][Shard:(0/1)][Intent:33554432] write Identity message, {"op":2,"d":{"token":"QQBot ACVM177qmAnQ-DzWgisBzlL0awx6-eti52kJLOV7P9zxccEa","intents":33554432,"shard":[0,1],"properties":{}},"Session":null}
[Info] 2026-03-02 06:26:22 client.go:214:readMessageToQueue [ws][ID:][Shard:(0/1)][Intent:33554432] receive Hello messag[Info] 2026-03-02 06:26:28 client.go:214:readMessageToQueue [ws][ID:][Shard:(0/1)][Intent:33554432] receive Hello message, {"d":{"heartbeat_interval":41250},"op":10}
[Info] 2026-03-02 06:26:28 client.go:214:readMessageToQueue [ws][ID:][Shard:(0/1)][Intent:33554432] receive InvalidSession message, {"op":9,"d":false}
[Error] 2026-03-02 06:26:28 client.go:198:readMessageToQueue [ws][ID:][Shard:(0/1)][Intent:33554432] read message failed, websocket: close 4924: session ip forbidden, message
[Error] 2026-03-02 06:26:28 client.go:92:Listening [ws][ID:][Shard:(0/1)][Intent:33554432] Listening stop. err is code:9005, text:invalid session, traceID:
[Info] 2026-03-02 06:26:28 client.go:244:listenMessageAndHandle [ws][ID:][Shard:(0/1)][Intent:33554432] message queue is closed
[Error] 2026-03-02 06:26:28 local.go:91:newConnect [ws/session] Listening err code:9005, text:invalid session, traceID:
panic: send on closed channel

goroutine 82 [running]:
github.com/open-dingtalk/dingtalk-stream-sdk-go/client.(*StreamClient).processLoop.func6()
/home/runner/go/pkg/mod/github.com/open-dingtalk/dingtalk-stream-sdk-go@v0.9.1/client/client.go:161 +0x22a
created by github.com/open-dingtalk/dingtalk-stream-sdk-go/client.(*StreamClient).processLoop in goroutine 61
/home/runner/go/pkg/mod/github.com/open-dingtalk/dingtalk-stream-sdk-go@v0.9.1/client/client.go:156 +0x2c5

[nikolasdehor]

The panic is in the DingTalk stream SDK, not in PicoClaw itself:

panic: send on closed channel

goroutine 82 [running]:
github.com/open-dingtalk/dingtalk-stream-sdk-go/client.(*StreamClient).processLoop.func6()
        client/client.go:161

This is a known bug in dingtalk-stream-sdk-go v0.9.1 (pinned in go.mod). The processLoop goroutine attempts to send on an internal channel that was already closed during reconnect or shutdown. When the QQ channel enters its reconnect loop after getting InvalidSession (opcode 9) and session ip forbidden (close code 4924), the DingTalk SDK running in parallel hits a race condition in its own process loop.

The QQ reconnect storm (visible in the logs: repeated Identity → InvalidSession → reconnect cycles at 06:26:18-06:26:28) does not directly cause the DingTalk panic, but both channels share the same process. The DingTalk SDK panic kills the entire process because there is no recover() guard around the DingTalk stream client goroutines.

PicoClaw does not wrap the DingTalk SDK goroutines with panic recovery. In pkg/channels/dingtalk/dingtalk.go, Start() (line 75) calls c.streamClient.Start(c.ctx) which spawns internal goroutines. There is no defer recover() anywhere in the DingTalk channel code.

Two fixes needed:

1. Upgrade dingtalk-stream-sdk-go — Check if v0.9.2+ fixes the send-on-closed-channel bug. If not, file an issue at github.com/open-dingtalk/dingtalk-stream-sdk-go.

2. Add panic recovery wrapper in PicoClaw — The channel manager or individual channel Start() methods should guard against third-party SDK panics. Something like:

go func() {
    defer func() {
        if r := recover(); r != nil {
            logger.ErrorCF("dingtalk", "DingTalk SDK panic recovered", map[string]any{
                "panic": fmt.Sprintf("%v", r),
            })
            // Optionally: trigger channel restart
        }
    }()
    if err := c.streamClient.Start(c.ctx); err != nil {
        // ...
    }
}()

This pattern is already used in some Go projects to isolate SDK panics from crashing the entire gateway.

For the QQ session ip forbidden issue: this happens when QQ detects the bot IP changed (common with dynamic IPs overnight). The SDK retries with a fresh Identity but QQ keeps rejecting because the IP is blocked for a cooldown period. The QQ channel should implement exponential backoff instead of immediate retry.

[sipeed-bot]

@atom12138 Hi! This issue has had no activity for over 2 weeks, so I'm closing it for now to keep things tidy. If it's still relevant, feel free to reopen it anytime and we'll pick it back up.