We were having problems where we were suspiciously processing notices
at a rate of 1 notice per 15s, which suggests that we the select was
timing out even though there were notices to be fetched immediately.
We fix this by clearing the queue each time our select loop ends.
(imported from commit 7e7bfbb2126d1f4170d65d1483a0b799dcab80b9)
When we send a message, we send some presence information to Tornado
to help it figure out how to generate emails for idle recipients of
a message. This change limits the presence info to being the
intersection of present users and recipients of the message. It is
just an internal optimization to avoid queueing up unneeded data.
The history behind this feature is that I implemented it a while
back, but I think I made a rebase mistake that sent all the presence
data over the wire, despite having code to filter on recipients.
It was mostly harmless, just leading to some inefficiency which is
now fixed.
(imported from commit 7c8e97705afb299c67b99053909e952fbc823551)
When you load the activity report, it will just show summary
counts for realms, but if you click on a realm, you will see
details about users in the realms. You can also click "Show all"
to see an interleaved view of realms and users.
(imported from commit b106557b1fae64d525071afc124b5a8aed319086)
Add rows to the activity report that roll up counts for all
users on each realm, to go along with individual users.
(imported from commit 8104f3ef7fbe406fe0fd2ba1bb00ce76a1ccbee5)
`Cannot read property 'flags' of undefined` in the
_.each callback in expand_summary_row.
Messages loaded when you scroll up in a narrow are not added to
all_msg_list. Because the user just clicked the message, we know
the message is in current_msg_list, so use that instead.
(imported from commit e76449a2a2748b96f69a2ab05d288b708d9e3ac0)
* I forgot to add a worker for user_activity_interval
* user_activity_interval and user_presence weren't in the humbug-workers group
(imported from commit 61c29e54a0dff621a913b3e8491db41f4d0a3909)
Before these examples weren't obviously blocking calls (they seemed
more like a callback registration, which may make more sense in the future)
(imported from commit 78fdf98d791b19843526437c710901d8dff62e8c)
The overall message charset may be null or not match the part's
charset. Even though it's unclear from the documentation,
experimentally using the charset for a message part seems to give you
the charset even for non-multipart emails.
(imported from commit 0e1d23073f4c53041f9760e66a6635f8a94893d1)
For a 4-person stream, we were hitting the DB 8 times, and 4 of
those queries were to lazily get user.email for the 4 recipients
due to upstream code using only(). I added user_profile__email
to the only() call.
I believe this regression started 9/18, and after pushing this
to prod, we would should look at this graph:
https://stats1.zulip.net/graphs/8274cd84588
(imported from commit 70629cb69fe5955c674ba76482609dfe78e5faaf)
This is useful in debugging when you just want to discard all the
messages in a queue because they have the wrong structure.
(imported from commit 8559ac74f11841430b4d0c801d5506ebcb74c3eb)
Instead of collapsing muted messages, just hide them altogether
in view where it makes sense to hide them.
(imported from commit 1c2c987ff302ceb135a025753cf421b4de1aea71)
Tim Abbott
Steve Howell
Jessica McKellar
Leo Franchi
Kevin Mehall
Zev Benjamin
Waseem Daher
acrefoot
Allen Rabinovich