Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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.
This commit is contained in:
Ryan Rehman 2020-06-16 21:28:37 +05:30 committed by Tim Abbott
parent 6637f2dbb7
commit 62aab0d9ee
3 changed files with 84 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
frontend_tests/node_tests/message_fetch.js
View File

@ -84,10 +84,12 @@ function config_fake_channel(conf) {
let called;
channel.get = function (opts) {
if (called) {
if (called && !conf.can_call_again) {
throw "only use this for one call";
}
if (!conf.can_call_again) {
assert(self.success === undefined);
}
assert.equal(opts.url, '/json/messages');
assert.deepEqual(opts.data, conf.expected_opts_data);
self.success = opts.success;
@ -306,6 +308,7 @@ run_test('loading_newer', () => {
const fetch = config_fake_channel({
expected_opts_data: data.req,
can_call_again: true,
});
message_fetch.maybe_load_newer_messages({
@ -361,7 +364,8 @@ run_test('loading_newer', () => {
// To handle this special case we should allow another fetch to occur,
// since the last message event's data had been discarded.
assert.equal(msg_list.data.fetch_status.can_load_newer_messages(), true);
// This fetch goes on until the newest message has been found.
assert.equal(msg_list.data.fetch_status.can_load_newer_messages(), false);
}());
(function test_home() {

62
static/js/fetch_status.js
View File

@ -2,11 +2,24 @@ const FetchStatus = function () {
const self = {};
// The FetchStatus object tracks tracks the state of a
// message_list_data object, whether rendered in the DOM or not,
// and is the source of truth for whether the message_list_data
// object has the complete history of the view or whether more
// messages should be loaded when scrolling to the top or bottom
// of the message feed.
let loading_older = false;
let loading_newer = false;
let found_oldest = false;
let found_newest = false;
let history_limited = false;
// Tracks the highest message ID that we know exist in this view,
// but are not within the contiguous range of messages we have
// received from the server. Used to correctly handle a rare race
// condition where a newly sent message races with fetching a
// group of messages that would lead to found_newest being set
// (described in detail below).
let expected_max_message_id = 0;
function max_id_for_messages(messages) {
@ -53,15 +66,58 @@ const FetchStatus = function () {
};
self.finish_newer_batch = function (messages, opts) {
// Returns true if and only if the caller needs to trigger an
// additional fetch due to the race described below.
const found_max_message_id = max_id_for_messages(messages);
if (opts.found_newest && expected_max_message_id > found_max_message_id) {
opts.found_newest = false;
}
loading_newer = false;
found_newest = opts.found_newest;
if (opts.update_loading_indicator) {
message_scroll.hide_loading_newer();
}
if (found_newest && expected_max_message_id > found_max_message_id) {
// This expected_max_message_id logic is designed to
// resolve a subtle race condition involving newly sent
// messages in a view that does not display the currently
// latest messages.
//
// When a new message arrives matching the current view
// and found_newest is false, we cannot add the message to
// the view in-order without creating invalid output
// (where two messages are displaye adjacent but might be
// weeks and hundreds of messages apart in actuality).
//
// So we have to discard those messages. Usually, this is
// fine; the client will receive those when the user
// scrolls to the bottom of the page, triggering another
// fetch. With that solution, a rare race is still possible,
// with this sequence:
//
// 1. Client initiates GET /messages to fetch the last
// batch of messages in this view. The server
// completes the database access and and starts sending
// the response with found_newest=true.
// 1. A new message is sent matching the view, the event reaches
// the client. We discard the message because found_newest=false.
// 1. The client receives the GET /messages response, and
// marks found_newest=true. As a result, it believes is has
// the latest messages and won't fetch more, but is missing the
// recently sent message.
//
// To address this problem, we track the highest message
// ID among messages that were discarded due to
// fetch_status in expected_max_message_id. If that is
// higher than the highest ID returned in a GET /messages
// response with found_newest=true, we know the above race
// has happened and trigger an additional fetch.
found_newest = false;
// Resetting our tracked last message id is an important
// circuit-breaker for cases where the message(s) that we
// "know" exist were deleted or moved to another topic.
expected_max_message_id = 0;
return true;
}
return false;
};
self.can_load_newer_messages = function () {

15
static/js/message_fetch.js
View File

@ -56,7 +56,7 @@ function process_result(data, opts) {
stream_list.maybe_scroll_narrow_into_view();
if (opts.cont !== undefined) {
opts.cont(data);
opts.cont(data, opts);
}
}
@ -83,7 +83,8 @@ function get_messages_success(data, opts) {
}
if (opts.num_after > 0) {
opts.msg_list.data.fetch_status.finish_newer_batch(data.messages, {
opts.fetch_again = opts.msg_list.data.fetch_status.finish_newer_batch(
data.messages, {
update_loading_indicator: update_loading_indicator,
found_newest: data.found_newest,
});
@ -92,7 +93,8 @@ function get_messages_success(data, opts) {
// the fetch_status data structure for message_list.all,
// which is never rendered (and just used for
// prepopulating narrowed views).
message_list.all.data.fetch_status.finish_newer_batch(data.messages, {
opts.fetch_again = message_list.all.data.fetch_status.finish_newer_batch(
data.messages, {
update_loading_indicator: false,
found_newest: data.found_newest,
});
@ -326,11 +328,18 @@ exports.maybe_load_newer_messages = function (opts) {
const anchor = exports.get_frontfill_anchor(msg_list).toFixed();
function load_more(data, args) {
if (args.fetch_again && args.msg_list === current_msg_list) {
exports.maybe_load_newer_messages({ msg_list: current_msg_list });
}
}
exports.load_messages({
anchor: anchor,
num_before: 0,
num_after: consts.forward_batch_size,
msg_list: msg_list,
cont: load_more,
});
};