Steve Howell bb3ecb178a Fix bugs related to batching message events. ...

This is general fix that makes sure that we
apply all message-modifying events after we
apply the events for the initial incoming
messages.

The particular scenario that was reported here
was when you would have two tabs for Zulip,
with one of them open and in a PM view, and
with the open tab being at the bottom of the
feed, such that incoming messages would be
immediately visible.

Now suppose the other person in that PM
conversation sent you a message.

The open tab would properly immediately
mark the message as read, and notify
the server.  The problem was that the closed
tab would not process the main message event
until it "woke up", by which time the flag-update
event was bundled into the same event batch
as the main message event.  We'd then process
the flag-update first, which essentially was
a noop, since the actual message wasn't in
the message store yet.  The user would then
see unread counts increment in the closed tab,
while the open tab didn't increment.  This
was confusing.

Now `server_events.js` processes the actual
message first and does the flag-update as part of a
`post_message_events` loop.

We include events for updating message flags,
deleting messages, and attaching submessages
to messages in the `post_message_events` array.

This bug was a bit difficult to simulate in a dev
environment, since you needed your "open" tab
to be in focus to simulate the race, but as
soon as you tab to another place to deliver
a message (whether from the browser or otherwise),
the open tab is no longer in focus.

I did this in the console of my "open"
tab to work around it:

    unread_ops.process_visible = unread_ops.mark_current_list_as_read;

This problem was easy to reproduce, but it wasn't
entirely consistent.  I often needed to send
several messages in succession to trigger event
batching and force the race condition.  (This wasn't
precisely a "race", as events actually arrive in the
correct order; it was having them arrive in the same
batch that triggered the bug.)

2018-08-26 22:26:28 -07:00

10 KiB

Raw Blame History

View Raw