Ryan Rehman 62aab0d9ee message view: Fetch again when "newest" is discarded. ...

The previous commit introduced a bug where it was not intuitive
for the user to scroll again.
For the current narrow, new messages were fetched again only when
scrolled to the bottom as usually there are many messages displayed.

However when the edge case mentioned in the previous commit
occured, it was not very obvious that a scroll should be done
or we could already be at the bottom and could not scroll again
to trigger a fetch.
`message_viewport.at_bottom` has a relevant comment explaining
this behaviour.

The previous commit handled the rare race condition. However,
there is a possibility that the rare race condition might occur
again while we are handling the previous condition.

This commit resolves these 2 problems by performing a re-fetch
while also resetting the `expected_max_message_id` and this
approach has two benefits:

1. The reset prevents an infinite loop, if somehow the expected
   max message's id gets corrupted resulting in a situation
   where the server can never send an id greater than that even
   after fetching.

2. Even though we stop after just one re-fetch the race condition
   might recursively occur while we handle the previous race
   condition. And even though the reset prevents multiple re-fetches,
   we don't have the missing message problem.

   This is because we treat the next race condition as a new race
   condition instead of it being a continuation of the previous.

   The `expected_max_message_id` gets updated again, on receiving
   a new message. Thus it can again enter the `fetch_status` block
   as the reset value is updated again.

2020-06-16 11:11:16 -07:00

14 KiB

Raw Blame History

View Raw