We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
我们如何感知断开? 通过事件不能保证,只能通过调用grpc event方法时传一个参数来告诉server端最后一条事件是什么。
如果只处理Message: 那我们可以在调用event时传一个最后一条Message的id,然后底层根据id反查从该id的消息到现在的时间点的消息,把这些消息emit出去。
如果要处理所有事件: 那么我们可以新建一个表,把所有事件和payload和timestamp都塞进去。当bot调用event时,带上最后一条事件的时间,然后把该时间点到现在的所有事件都emit出去。这个表可以每天清理一次。
The text was updated successfully, but these errors were encountered:
暂时不考虑中间漏事件的情况。即底层事件a->b->c,ac收到了b漏了。
Sorry, something went wrong.
计划采取以下措施: server端在grpc的Event payload中添加seq,并入库。当client端收到事件后,更新seq(只增加)。在连接EventStream的时候,如果存了seq,则传过去,server端根据seq将之后的事件再抛出。
可能client端也需要记录timestamp,并将seq落盘,以应对bot重启的情况和bot离线时间较长的情况。
juzibot/wechaty-grpc#44
No branches or pull requests
我们如何感知断开?
通过事件不能保证,只能通过调用grpc event方法时传一个参数来告诉server端最后一条事件是什么。
如果只处理Message:
那我们可以在调用event时传一个最后一条Message的id,然后底层根据id反查从该id的消息到现在的时间点的消息,把这些消息emit出去。
如果要处理所有事件:
那么我们可以新建一个表,把所有事件和payload和timestamp都塞进去。当bot调用event时,带上最后一条事件的时间,然后把该时间点到现在的所有事件都emit出去。这个表可以每天清理一次。
The text was updated successfully, but these errors were encountered: