zulip/web/tests/message_fetch.test.js

469 lines
12 KiB
JavaScript
Raw Normal View History

"use strict";
const {strict: assert} = require("assert");
const _ = require("lodash");
const {mock_esm, set_global, zrequire} = require("./lib/namespace");
const {run_test} = require("./lib/test");
const $ = require("./lib/zjquery");
const {page_params} = require("./lib/zpage_params");
set_global("document", "document-stub");
const noop = () => {};
function MessageListView() {
return {
maybe_rerender: noop,
append: noop,
prepend: noop,
};
}
mock_esm("../src/message_list_view", {
MessageListView,
});
mock_esm("../src/recent_topics_ui", {
process_messages: noop,
show_loading_indicator: noop,
hide_loading_indicator: noop,
});
mock_esm("../src/ui_report", {
hide_error: noop,
});
const channel = mock_esm("../src/channel");
const message_helper = mock_esm("../src/message_helper");
const message_lists = mock_esm("../src/message_lists");
const message_util = mock_esm("../src/message_util");
const stream_list = mock_esm("../src/stream_list", {
maybe_scroll_narrow_into_view() {},
});
mock_esm("../src/message_scroll", {
show_loading_older: noop,
hide_loading_older: noop,
show_loading_newer: noop,
hide_loading_newer: noop,
update_top_of_narrow_notices() {},
});
set_global("document", "document-stub");
const message_fetch = zrequire("message_fetch");
const {all_messages_data} = zrequire("all_messages_data");
const {Filter} = zrequire("../src/filter");
const message_list = zrequire("message_list");
const people = zrequire("people");
const alice = {
email: "alice@example.com",
user_id: 7,
full_name: "Alice",
};
people.add_active_user(alice);
function make_home_msg_list() {
const table_name = "whatever";
const filter = new Filter();
const list = new message_list.MessageList({
table_name,
filter,
});
return list;
}
function reset_lists() {
message_lists.home = make_home_msg_list();
message_lists.current = message_lists.home;
all_messages_data.clear();
}
function config_fake_channel(conf) {
const self = {};
let called;
let called_with_newest_flag = false;
channel.get = (opts) => {
assert.equal(opts.url, "/json/messages");
// There's a separate call with anchor="newest" that happens
// unconditionally; do basic verification of that call.
if (opts.data.anchor === "newest") {
assert.ok(!called_with_newest_flag, "Only one 'newest' call allowed");
called_with_newest_flag = true;
assert.equal(opts.data.num_after, 0);
return;
}
assert.ok(!called || conf.can_call_again, "only use this for one call");
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 17:58:37 +02:00
if (!conf.can_call_again) {
assert.equal(self.success, undefined);
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 17:58:37 +02:00
}
assert.deepEqual(opts.data, conf.expected_opts_data);
self.success = opts.success;
called = true;
};
return self;
}
function config_process_results(messages) {
const self = {};
narrow: Fix messages being cached without flags set. f0c680e9c0d1a62fd414bccc82e4ac255173aaa9 introduced a call to message_helper.process_new_message without first calling message_store.set_message_flags on the message. This resulted in it being possible as a race, when loading the Zulip app to a stream/topic/near narrow, for a message to have the `historical` flag be undefined due to not being initialized. That invalid state, in turn, resulted in the message_list_view code path for rendering the message feed incorrectly displaying additional recipient bars around the message. We could fix this by just calling message_store.set_message_booleans in this code path. However, this bug exposes the fact that it's very fragile to expect every code path to call that function before message_helper.process_new_message. So we instead fix this by moving message_store.set_message_booleans inside message_helper.process_new_message. One call point of concern in this change is maybe_add_narrow_messages, which could theoretically reintroduce the double set_message_flags bugs detailed in 9729b1a4ad51b69c98ce4f8374c9d9f8cf69430c. However, I believe that to not be possible, because that call should never experience a cache miss. The other existing code paths were already calling set_message_booleans immediately before message_helper.process_new_message. They are still changing here, in that we now do a cache lookup before attempting to call set_message_booleans. Because the message booleans do not affect the cache lookup and the local message object is discarded in case of a cache hit, this should have no functional impact. Because I found the existing comment at that call site confusing and almost proposed removing it as pointless, extend the block comment to explicitly mention that the purpose is refreshing our object. Fixes #21503.
2022-03-24 01:07:56 +01:00
const messages_processed_for_new = [];
narrow: Fix messages being cached without flags set. f0c680e9c0d1a62fd414bccc82e4ac255173aaa9 introduced a call to message_helper.process_new_message without first calling message_store.set_message_flags on the message. This resulted in it being possible as a race, when loading the Zulip app to a stream/topic/near narrow, for a message to have the `historical` flag be undefined due to not being initialized. That invalid state, in turn, resulted in the message_list_view code path for rendering the message feed incorrectly displaying additional recipient bars around the message. We could fix this by just calling message_store.set_message_booleans in this code path. However, this bug exposes the fact that it's very fragile to expect every code path to call that function before message_helper.process_new_message. So we instead fix this by moving message_store.set_message_booleans inside message_helper.process_new_message. One call point of concern in this change is maybe_add_narrow_messages, which could theoretically reintroduce the double set_message_flags bugs detailed in 9729b1a4ad51b69c98ce4f8374c9d9f8cf69430c. However, I believe that to not be possible, because that call should never experience a cache miss. The other existing code paths were already calling set_message_booleans immediately before message_helper.process_new_message. They are still changing here, in that we now do a cache lookup before attempting to call set_message_booleans. Because the message booleans do not affect the cache lookup and the local message object is discarded in case of a cache hit, this should have no functional impact. Because I found the existing comment at that call site confusing and almost proposed removing it as pointless, extend the block comment to explicitly mention that the purpose is refreshing our object. Fixes #21503.
2022-03-24 01:07:56 +01:00
message_helper.process_new_message = (message) => {
messages_processed_for_new.push(message);
return message;
};
message_util.do_unread_count_updates = (arg) => {
assert.deepEqual(arg, messages);
};
message_util.add_old_messages = (new_messages, msg_list) => {
assert.deepEqual(new_messages, messages);
msg_list.add_messages(new_messages);
};
stream_list.update_streams_sidebar = noop;
self.verify = () => {
narrow: Fix messages being cached without flags set. f0c680e9c0d1a62fd414bccc82e4ac255173aaa9 introduced a call to message_helper.process_new_message without first calling message_store.set_message_flags on the message. This resulted in it being possible as a race, when loading the Zulip app to a stream/topic/near narrow, for a message to have the `historical` flag be undefined due to not being initialized. That invalid state, in turn, resulted in the message_list_view code path for rendering the message feed incorrectly displaying additional recipient bars around the message. We could fix this by just calling message_store.set_message_booleans in this code path. However, this bug exposes the fact that it's very fragile to expect every code path to call that function before message_helper.process_new_message. So we instead fix this by moving message_store.set_message_booleans inside message_helper.process_new_message. One call point of concern in this change is maybe_add_narrow_messages, which could theoretically reintroduce the double set_message_flags bugs detailed in 9729b1a4ad51b69c98ce4f8374c9d9f8cf69430c. However, I believe that to not be possible, because that call should never experience a cache miss. The other existing code paths were already calling set_message_booleans immediately before message_helper.process_new_message. They are still changing here, in that we now do a cache lookup before attempting to call set_message_booleans. Because the message booleans do not affect the cache lookup and the local message object is discarded in case of a cache hit, this should have no functional impact. Because I found the existing comment at that call site confusing and almost proposed removing it as pointless, extend the block comment to explicitly mention that the purpose is refreshing our object. Fixes #21503.
2022-03-24 01:07:56 +01:00
assert.deepEqual(messages_processed_for_new, messages);
};
return self;
}
function message_range(start, end) {
return _.range(start, end).map((idx) => ({
js: Convert _.map(a, …) to a.map(…). And convert the corresponding function expressions to arrow style while we’re here. import * as babelParser from "recast/parsers/babel"; import * as recast from "recast"; import * as tsParser from "recast/parsers/typescript"; import { builders as b, namedTypes as n } from "ast-types"; import K from "ast-types/gen/kinds"; import fs from "fs"; import path from "path"; import process from "process"; const checkExpression = (node: n.Node): node is K.ExpressionKind => n.Expression.check(node); for (const file of process.argv.slice(2)) { console.log("Parsing", file); const ast = recast.parse(fs.readFileSync(file, { encoding: "utf8" }), { parser: path.extname(file) === ".ts" ? tsParser : babelParser, }); let changed = false; recast.visit(ast, { visitCallExpression(path) { const { callee, arguments: args } = path.node; if ( n.MemberExpression.check(callee) && !callee.computed && n.Identifier.check(callee.object) && callee.object.name === "_" && n.Identifier.check(callee.property) && callee.property.name === "map" && args.length === 2 && checkExpression(args[0]) && checkExpression(args[1]) ) { const [arr, fn] = args; path.replace( b.callExpression(b.memberExpression(arr, b.identifier("map")), [ n.FunctionExpression.check(fn) || n.ArrowFunctionExpression.check(fn) ? b.arrowFunctionExpression( fn.params, n.BlockStatement.check(fn.body) && fn.body.body.length === 1 && n.ReturnStatement.check(fn.body.body[0]) ? fn.body.body[0].argument || b.identifier("undefined") : fn.body ) : fn, ]) ); changed = true; } this.traverse(path); }, }); if (changed) { console.log("Writing", file); fs.writeFileSync(file, recast.print(ast).code, { encoding: "utf8" }); } } Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-02-08 02:43:49 +01:00
id: idx,
}));
}
const initialize_data = {
initial_fetch: {
req: {
anchor: "first_unread",
num_before: 200,
num_after: 200,
client_gravatar: true,
},
resp: {
messages: message_range(201, 801),
found_newest: false,
anchor: 444,
},
},
forward_fill: {
req: {
anchor: "800",
num_before: 0,
num_after: 1000,
client_gravatar: true,
},
resp: {
messages: message_range(800, 1000),
found_newest: true,
},
},
back_fill: {
req: {
anchor: "201",
num_before: 1000,
num_after: 0,
client_gravatar: true,
},
resp: {
messages: message_range(100, 200),
found_oldest: true,
},
},
};
function test_fetch_success(opts) {
const response = opts.response;
const messages = response.messages;
const process_results = config_process_results(messages);
opts.fetch.success(response);
process_results.verify();
}
function initial_fetch_step(home_view_loaded) {
const self = {};
let fetch;
const response = initialize_data.initial_fetch.resp;
self.prep = () => {
fetch = config_fake_channel({
expected_opts_data: initialize_data.initial_fetch.req,
});
message_fetch.initialize(home_view_loaded);
};
self.finish = () => {
test_fetch_success({
fetch,
response,
});
};
return self;
}
function forward_fill_step() {
const self = {};
let fetch;
self.prep = () => {
fetch = config_fake_channel({
expected_opts_data: initialize_data.forward_fill.req,
});
};
self.finish = () => {
const response = initialize_data.forward_fill.resp;
let idle_config;
$("document-stub").idle = (config) => {
idle_config = config;
};
test_fetch_success({
fetch,
response,
});
assert.equal(idle_config.idle, 10000);
return idle_config;
};
return self;
}
function test_backfill_idle(idle_config) {
const fetch = config_fake_channel({
expected_opts_data: initialize_data.back_fill.req,
});
const response = initialize_data.back_fill.resp;
idle_config.onIdle();
test_fetch_success({
fetch,
response,
});
}
run_test("initialize", () => {
reset_lists();
let home_loaded = false;
page_params.unread_msgs = {
old_unreads_missing: false,
};
function home_view_loaded() {
home_loaded = true;
}
const step1 = initial_fetch_step(home_view_loaded);
step1.prep();
const step2 = forward_fill_step();
step2.prep();
step1.finish();
assert.ok(!home_loaded);
const idle_config = step2.finish();
assert.ok(home_loaded);
test_backfill_idle(idle_config);
});
2018-03-23 17:32:24 +01:00
function simulate_narrow() {
const filter = new Filter([{operator: "pm-with", operand: alice.email}]);
2018-03-23 17:32:24 +01:00
const msg_list = new message_list.MessageList({
table_name: "zfilt",
filter,
});
message_lists.current = msg_list;
2018-03-23 17:32:24 +01:00
return msg_list;
}
run_test("loading_newer", () => {
2018-03-23 17:32:24 +01:00
function test_dup_new_fetch(msg_list) {
assert.equal(msg_list.data.fetch_status.can_load_newer_messages(), false);
2018-03-23 17:32:24 +01:00
message_fetch.maybe_load_newer_messages({
msg_list,
2018-03-23 17:32:24 +01:00
});
}
function test_happy_path(opts) {
const msg_list = opts.msg_list;
const data = opts.data;
2018-03-23 17:32:24 +01:00
const fetch = config_fake_channel({
2018-03-23 17:32:24 +01:00
expected_opts_data: data.req,
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 17:58:37 +02:00
can_call_again: true,
2018-03-23 17:32:24 +01:00
});
// The msg_list is empty and we are calling frontfill, which should
// raise fatal error.
if (opts.empty_msg_list) {
assert.throws(
() => {
message_fetch.maybe_load_newer_messages({
msg_list,
show_loading: noop,
hide_loading: noop,
});
},
{
name: "Error",
message: "There are no message available to frontfill.",
},
);
} else {
message_fetch.maybe_load_newer_messages({
msg_list,
show_loading: noop,
hide_loading: noop,
});
test_dup_new_fetch(msg_list);
test_fetch_success({
fetch,
response: data.resp,
});
}
2018-03-23 17:32:24 +01:00
}
(function test_narrow() {
const msg_list = simulate_narrow();
page_params.unread_msgs = {
old_unreads_missing: true,
};
2018-03-23 17:32:24 +01:00
const data = {
2018-03-23 17:32:24 +01:00
req: {
anchor: "444",
2018-03-23 17:32:24 +01:00
num_before: 0,
num_after: 100,
narrow: `[{"negated":false,"operator":"pm-with","operand":[${alice.user_id}]}]`,
2018-03-23 17:32:24 +01:00
client_gravatar: true,
},
resp: {
messages: message_range(500, 600),
found_newest: false,
},
};
test_happy_path({
msg_list,
data,
empty_msg_list: true,
});
msg_list.append_to_view = () => {};
// Instead of using 444 as page_param.pointer, we
// should have a message with that id in the message_list.
msg_list.append(message_range(444, 445), false);
test_happy_path({
msg_list,
data,
empty_msg_list: false,
2018-03-23 17:32:24 +01:00
});
assert.equal(msg_list.data.fetch_status.can_load_newer_messages(), true);
message list: Render new messages only after "newest" is found. If a user sends a message while the latest batch of messages are being fetched, the new message recieved from `server_events` gets displayed temporarily out of order (just after the the current batch of messages) for the current narrow. We could just discard the new message events if we havent recieved the last message i.e. when `found_newest` = False, since we would recieve them on furthur fetching of that narrow. But this would create another bug where the new messages sent while fetching the last batch of messages would not get rendered. Because, `found_newest` = True and we would no longer fetch messages for that narrow, thus the new messages would not get fetched and are also discarded from the events codepath. Thus to resolve both these bugs we use the following approach: * We do not add the new batch of messages for the current narrow while `has_found_newest` = False. * We store the latest message id which should be displayed at the bottom of the narrow in `fetch_status`. * Ideally `expected_max_message_id`'s value should be equal to the last item's id in `MessageListData`. * So the messages received while `has_found_newest` = False, will be fetched later and also the `expected_max_message_id` value gets updated. * And after fetching the last batch where `has_found_newest` = True, we would again fetch messages if the `expected_max_message_id` is greater than the last message's id found on fetching by refusing to update the server provided `has_found_newest` = True in `fetch_status`. Another benefit of not discarding the events is that the message gets processed not rendered i.e. we still get desktop notifications and unread count updates. Fixes #14017
2020-05-30 17:34:07 +02:00
// The server successfully responded with messages having id's from 500-599.
// We test for the case that this was the last batch of messages for the narrow
// so no more fetching should occur.
// And also while fetching for the above condition the server received a new message
// event, updating the last message's id for that narrow to 600 from 599.
data.resp.found_newest = true;
msg_list.data.fetch_status.update_expected_max_message_id([{id: 600}]);
test_happy_path({
msg_list,
data,
message list: Render new messages only after "newest" is found. If a user sends a message while the latest batch of messages are being fetched, the new message recieved from `server_events` gets displayed temporarily out of order (just after the the current batch of messages) for the current narrow. We could just discard the new message events if we havent recieved the last message i.e. when `found_newest` = False, since we would recieve them on furthur fetching of that narrow. But this would create another bug where the new messages sent while fetching the last batch of messages would not get rendered. Because, `found_newest` = True and we would no longer fetch messages for that narrow, thus the new messages would not get fetched and are also discarded from the events codepath. Thus to resolve both these bugs we use the following approach: * We do not add the new batch of messages for the current narrow while `has_found_newest` = False. * We store the latest message id which should be displayed at the bottom of the narrow in `fetch_status`. * Ideally `expected_max_message_id`'s value should be equal to the last item's id in `MessageListData`. * So the messages received while `has_found_newest` = False, will be fetched later and also the `expected_max_message_id` value gets updated. * And after fetching the last batch where `has_found_newest` = True, we would again fetch messages if the `expected_max_message_id` is greater than the last message's id found on fetching by refusing to update the server provided `has_found_newest` = True in `fetch_status`. Another benefit of not discarding the events is that the message gets processed not rendered i.e. we still get desktop notifications and unread count updates. Fixes #14017
2020-05-30 17:34:07 +02:00
});
// To handle this special case we should allow another fetch to occur,
// since the last message event's data had been discarded.
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 17:58:37 +02:00
// This fetch goes on until the newest message has been found.
assert.equal(msg_list.data.fetch_status.can_load_newer_messages(), false);
})();
2018-03-23 17:32:24 +01:00
(function test_home() {
reset_lists();
const msg_list = message_lists.home;
2018-03-23 17:32:24 +01:00
const data = [
2018-03-23 17:32:24 +01:00
{
req: {
anchor: "444",
2018-03-23 17:32:24 +01:00
num_before: 0,
num_after: 100,
client_gravatar: true,
},
resp: {
messages: message_range(500, 600),
found_newest: false,
},
},
{
req: {
anchor: "599",
2018-03-23 17:32:24 +01:00
num_before: 0,
num_after: 100,
client_gravatar: true,
},
resp: {
messages: message_range(700, 800),
found_newest: true,
},
},
];
test_happy_path({
msg_list,
2018-03-23 17:32:24 +01:00
data: data[0],
empty_msg_list: true,
});
all_messages_data.append(message_range(444, 445), false);
test_happy_path({
msg_list,
data: data[0],
empty_msg_list: false,
2018-03-23 17:32:24 +01:00
});
assert.equal(msg_list.data.fetch_status.can_load_newer_messages(), true);
2018-03-23 17:32:24 +01:00
test_happy_path({
msg_list,
2018-03-23 17:32:24 +01:00
data: data[1],
});
assert.equal(msg_list.data.fetch_status.can_load_newer_messages(), false);
})();
});