收到新消息，未调用 conversation.read()，刷新后获取会话列表时，unreadMessagesCount 变为 0

[musicode]

如题

[musicode]

不新开 issue 了，v4.0.0-beta.4 没发到 npm...

[musicode]

@leeyeh 两个设备，A 未登录，B 给 A 发 20 条消息，此时，A 登录，会连续触发 message 回调，且收到消息的顺序，和发送消息的顺序不一致，并且未读消息数也不是 20，这是不是一个 bug 啊

[musicode]

此外，这20条消息当中，有些还漏掉了

[leeyeh]

你用的是这个模式：https://leancloud.cn/docs/realtime_guide-js.html#hash-422012010

[musicode]

感觉未读消息数还是有 bug，偶现数字不对的情况，暂时不知道怎么复现

[purefun]

@leeyeh 能否在 https://leancloud.cn/docs/realtime_guide-js.html#hash-422012010 中写明清楚开启离线消息推送的副作用？

[leeyeh]

在登录之后会发生两件事：

• 执行 query，得到 conversaion 列表
• 服务端主动推送未读数过来

这两个事情的顺序是不能确定的。

如果服务端的未读数通知先到，那么 SDK 会缓存这个 conversation（这时候 unreadMessageCont 是 2），然后 query 结果到了，SDK 更新缓存的 conversation。此时一切都符合预期（unreadMessageCont 还是 2）。 如果 query 的结果先到，那么这时候打印 conversation.unreadMessagesCount 会是 0（因为 query 结果是不含 unread 数的），然后服务端的未读数通知到了，此时 SDK 会将这个 conversation 的 unreadMessageCont 更新为 2。

不管顺序如何，最终，我们都会收到一次 UNREAD_MESSAGES_COUNT_UPDATE 事件，并且 conversation 的 unreadMessageCont 值为 2。这是 SDK 能保证的，因此如果你用的是现代的前端框架，并且在 UNREAD_MESSAGES_COUNT_UPDATE 时更新了 View，那么最终的显示结果一定是对的。