Later, we can fork off a separate process to do that task, but for
now, we can just rely on the fact that unless the server was just
rebooted, the relevant messages will already be in that cache, and
even if it was, getting the needed messages once each is not a
particularly expensive query.
(imported from commit 6d08eba1b41237fd4e1204e181ce8f227573930d)
This allows us to handle the return_messages_immediately part of
get_updates requests without having to talk to the database.
(imported from commit ed0b7742d359efb21a0a4960f4fc25f4337e9ad4)
This code is from a previous protocol where the users array was posted
as a comma-separate list, rather than encoded via json.
(imported from commit 3a2edfcbf250a7eef305b2e98018c1361cc2fffe)
This is for consistency with the rest of our code dealing with message
delivery, which always uses the user_profile_id.
(imported from commit 5bf10bb9b994b0a98d3a22bd0bd86e542ab8a2ee)
Previously, if last was None, we wouldn't check dont_block,
server_generation, or any of the other reasons that get_updates might
return immediately, and just unconditionally entered longpolling mode.
In the process, this reorders return_messages_immediately to have
fewer cases and thus be easier to read.
(imported from commit 67803b8bfc7d9c9c1a4d6916eb2fb62664fb35a9)
This check was a workaround for the fact that the browser client
submitted a "last" value of -1.
(imported from commit a668f6a4e7a0c027f1214166a9bbf40d29b5daeb)
We shouldn't deploy this change until strictly after we deploy
"Fix website improperly submitting a last value of -1."
or we will break website clients.
(imported from commit 7f682ab0f7060b677f53f0a0073faef216f45d00)