You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 27, 2022. It is now read-only.
NoneBot 日志:
酷Q 和 CQHTTP 日志:
Bug 整体表现是用户密集发送消息后,从刚开始的某个消息开始,机器人不再响应,卡了很久之后,才会继续响应。
本次测试中,根据 NoneBot 日志,从
12:45:52,092
卡到了12:48:02,563
,大约为 2 分 10 秒(这么整的时间还是有点可疑的),期间没有任何日志。但与此同时 CQHTTP 仍在上报事件,并显示事件上报成功。由于 CQHTTP 通过 WebSocket 上报,只根据发送状态来确认是否上报成功,因此不能确认 NoneBot 是不是在那个时刻确实收到了事件上报并且相应的事件回调函数是否被调用,也就是说不能确定没有日志的那个时间段,事件数据是在 WebSocket 连接的缓冲区,还是已经进行回调并由下面的代码创建了 asyncio task:但可以肯定的是,这个 task 一定没有被运行,即使存在也是在 event loop 里没有被调度。
另外,第一个被卡住(或者说可能是唯一的罪魁祸首)的操作是牛牛发送的「小金库」的回复。下面这段日志是牛牛的「小金库」消息的完整处理日志:
可以看到命令已经运行完成了,但消息实际上在卡住的时间段之后才真正发出(调用到 CQHTTP)。小金库命令使用了
session.finish()
来发送消息,内部使用asyncio.ensure_future()
,也就是说,这个 task 一定被创建了,但 2 分 10 秒之后才被调度,跟上面所说的后续事件上报也卡死的情形有点相似,所以这个asyncio.ensure_future()
非常可疑。另外,由于命令已经运行完成,应该已经跟数据库没有任何关系。总的来说,event loop 这边有两种可能性:
session.finish()
发送消息时)卡死后,事件上报数据在 WebSocket 缓冲区session.finish()
发送消息时)卡死后,事件上报数据已被收到,事件回调也被调用,但创建的 task 在 event loop 中因为某种原因(很可能和session.finish()
发送失败的原因相同)未被调度消息发送卡死有几种可能性:
asyncio.ensure_future()
创建的 task 很久没有被调度(有可能是因为有隐藏的同步阻塞操作?)The text was updated successfully, but these errors were encountered: