Tornado reloads the app whenever there is a change in code. Due to this,
new connection is created to the client which also results in a new
channel. To avoid creating two channels for the queue in the RabbitMQ
broker we should close the old channel. Otherwise messages sent to the
queue will be distributed among these two channels in a round robin
scheme and we will end up losing one message since one of the channels
doesn't have an active consumer.
This commit closes the connection to the queue whenever Tornado reloads
the application using add_reload_hook().
Fixes#5824.
While demoing Zulip at PyCon, I learned that it is hard to
distinguish topics from streams in our left sidebar.
Indenting them by a few pixel seems to make it more clear
that topics belong to a stream.
We do not need to test the exception message being logged in every
test case where an exception is raised by a webhook function.
Testing it once should be enough; this makes the tests less
verbose.
If an incoming payload contained a unicode character, it raised
a UnicodeEncodeError, because the message template was an str. Now,
the message template is unicode, so it can be formatted to include
unicode characters, should the incoming payloads contain any.
Splitting bot_lib.py file into 2 files led to unnecessary
redirection of the code workflow. For an embedded bot/service to
send a reply, it was being redirected 3 times.
First, the code flow comes to "EmbeddedBotHandler" class to send
reply, then it goes to the common function in "zulip_bots/lib.py",
then it would come back to "EmbeddedBotHandler". Later on, if we
create an abstract class, from where the bot work flow would
directly hit and then from there it is classified into
EmbeddedBotHandler or ExternalBotHandler and accordingly it would
get redirected.
Now, first the bot flow goes to it's handler class External or
Embedded (where we pass that this is External or Embedded bot as
parameter) and then goes to a common point and then comes back to
the same class.
We used to generate a file at this path in the static build,
but since 3f5d0e69f the corresponding output goes into
static/webpack-bundles instead. Clear the now-dead path
from our gitignore files.
We generate a docs/_build/coverage/, and a var/coverage/
(and the latter is mapped as the URL `/coverage/` in dev),
but those are covered (ahem) by other ignore patterns
that ignore their respective parents.
Also add a comment explaining an important non-obvious wrinkle in how
paths in the format are interpreted, and adjust some paths to a
consistent style.
Exception logging within api_key_only_webhook_view fails when
ValueError is raised if the request.body passed to ujson.loads
isn't valid JSON. In this case, we now just convert the payload
to a string and log that. This allows us to inspect JSON payloads
that aren't being decoded properly.
If you use the escape key to close a message edit, we need
to blur out the text fields. Otherwise, hotkeys.js thinks
we are still editing the text. This bug would disable the
use of things like arrow keys until the user subsequently
focused another field.
We probably eventually want hotkeys.js to be smarter about
ignoring hidden fields that still have the focus, but there's
also no reason not to blur the fields here, and this is a more
local, less risky fix.
Currently when hovering over the external link icon generated when a topic contains a
realm filter, an underline appears. This commit removes that underline.
static/ serves static files which get copied around per deploy. Since
the webpack stats files need a consistent name and change per deploy,
they can't live in static/.
This fixes a bug that preventing downgrading a Zulip server to an old
version.
This commit renames possibly_notify_new_messages_outside_viewport()
to the more concise name notify_local_mixes().
We really only need to call this function in one place, so we
have the caller check the `local_id` condition. We can eventually
upstream this code even further so that it's completely
obvious that it's only ever called from the local-echo codepath.
We were calling maybe_add_narrowed_messages() in a place
where local_id is guaranteed to be undefined, since
we always set local_id to undefined when
can_apply_locally() fails.
In turn maybe_add_narrowed_messages() was calling
possibly_notify_new_messages_outside_viewport(), which
requires a local_id to do anything meaningful.
This removes all the associated dead code--passing in
a parameter that we know always was undefined and
calling a function that we know always would no-op.
Not only does this simplify the code a bit, but it avoids
us stepping on the toes of the alternative code path that
deals with non-locally-echoed messages.
This commit early-exits before our loop when local_id is none,
and it tries to more clearly indicate that the callers will
generally be just calling this with messages sent on the
local-echo path.