This fixes a very rare exception seen in production, which the
previous assertion allowed us to understand was possible in a rare
race, now documented in comments.
See also 69e10b4dae.
Even though opts.msg_list can be undefined, we still want to retry
loading messages for it since our code needs that data regardless
of opts.msg_list being undefined.
Fixes#27208. Fixes#27207.
We only process messages from all_messages_data and special data
fetched for recent view only.
This avoids us having a conversation present in recent view which is
not contiguous due to loading a random old conversation.
Also, to ensure displayed conversations are contiguous while we are
loading data, we don't show message list data until we have found the
newest message in the list.
Fixes#27207
The recent view's data sources are mainly all_messages_data,
but if you click into a stream via the left sidebar that has
no recent conversation history, one can reliably reproduce that
some of those conversations will end up being displayed in the
recent view, despite not being temporally contiguous with what
it has data for.
To avoid it, we only process messages fetched for all message data.
Since load_messages now supports fetching data with only
MessageListData, we can just use it and avoid calling
MessageListView which also caused our polls and TODO widgets to
not render occasionally.
Expands support for the message ID operand for id" operator to be either
a string or an integer. Previously, this operand was always validated as
a string.
We now return "first_unread" as anchor from get_backfill_anchor in
case when the message list is empty instead of throwing an error.
Doing this, would just result in fetching the messages normally like
it happens when a user narrows to a stream by clicking on it from
sidebar.
This also helps us handling the case, when all messages in the
current stream narrow are removed due to moving them, by fetching
the other messages from server for that stream narrow.
I can't see any reason why it'd make sense to call a bunch of
functions designed to process newly arrived messages with an empty
list of messages to handle a 400 error from the server.
As best I can tell, the only part of this that was useful is showing
the appropriate empty narrow message.
Containing all the message_fetch logic for #connection-error inside
load_messages is considerably more readable, and will help with being
able to clean up the process_result hack.
Previously, when backfilling in a stream narrow (the main situation
where _items != _all_items), we would double-fetch any muted messages
older than the oldest message not hidden due to topic or user muting.
We change the all_messages fetch to use this function even though it
doesn't matter, just for clarity about the intent.
Since this bug could have prevented making progress fixes a
theoretical bug that could result in the client trying to fetch
messages for a given narrow indefinitely.
This function will allow us to adjust the codebase to write what it
means semantically -- whether a check is for the message list being
visibly empty, or completely empty.
In this commit, we leave the .empty() method incorrect, because
several other adjustments need to be made atomically with fixing it.
Adds support in the web app for `dm-including` operator.
This will deprecate the `group-pm-with` operator, but any changes
to that narrow operator will be in a separate commit since it
returns a different message query. The `group-pm-with` operator
only returned group direct messages, while the new `dm-including`
operator returns both group and 1-on-1 direct messages.
The general API changelog and documentation updates will be done
in a final commit in the series of commits that adds support for
the various new direct message narrows.
Adds support in the web app for `dm` operator. This will deprecate
the `pm-with` operator, but existing links/URLs are still supported
for backwards-compatilibity.
This commit updates the web app default behaviors to default to
the new narrow/URLs `dm/...` and `/#narrow/dm/...` when navigating
and searching in the app.
There is some general clean up of references to private messages
or PMs to be either direct messages or DMs in these changes.
The general API changelog and documentation updates will be done
in a final commit in the series of commits that adds support for
the various new direct message narrows.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <[email protected]>
