处于连接状态的socket，broadcast时被返回无效的信道ID

[idleb]

正处在websocket连接中的，设备经常收不到消息，心跳正常。发现tunnel broadcast的时候回返回无效的信道ID，这些无效的信道ID中包含了正在连接中的websock，如果直接从服务器维护的用户-信道ID映射列表中移除，这些正在连接中的用户就无法收到消息了。
不清楚信道服务器是如何判定无效的信道ID的，为什么websocket正常连接的情况下，会被判定为无效的信道？

[jas0ncn]

之前有存在我们发布信道服务导致的重启断线，现在还会吗？

[idleb]

我们当时做了一些改动：

1. 把broadcast返回无效的信道ID时移除用户-信道ID映射，修改为用户重连时移除

2. 添加了定时轮询检测消息完整性，触发客户端重连

现在，跑了一遍测试确实没有当时那么频繁了，但偶尔还是会有，不知道是不是因为多端的问题。
问题应该是在broadcast返回无效的信道ID的时候，客户端websock仍然能够ping通，建议服务端能断开websock来通知客户端重连

[jacksplwxy]

我是有两种情况出现无效信道：
1、业务服务器推送消息时，有时候node.js报错：(node:2927) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: ERR_UNKNOWN_TUNNEL_ERROR，这时小程序端收不到推送的消息，并且此时的信道有很大可能被判定为无效信道。
2、正常连接的信道被莫名其妙的判断为无效信道，并且此时小程序端也收不到信息。
所以我没有根据无效信道去维护用户-信道ID映射列表，而是业务完了再去清除用户信息。对于出现无效信道前端不能收到消息的情况，我会隔几秒钟尝试再次发送，有时能发送成功有时不能，所以此时被判定的无效信道ID其实有可能还是有效的。

@jas0ncn 上面提到的nodejs报错定位不到问题，不知如何处理掉？另外， 小程序端wx.connectSocket()发起连接请求后有时长时间监听不到open成功，这是什么原因？

[jas0ncn]

出现错误可能是信道本身错误引起的，可以尝试着重新广播一下消息，我们还在定位该问题，另外监听不到open我们也不大清楚哈，可以咨询一下微信

[RLee063]

这个问题现在解决了吗