Skip to content

Slow sometimes to replace event queue after expiry #809

Open
@gnprice

Description

@gnprice

When the app resumes after having been in the background for a while, or after the device was offline, its event queue on the server may have expired. (The server does this after 10 minutes of not getting any get-events requests for that queue.) Normally this is fine because we just make a new one: that was #185 / #466.

That mechanism does work, because I regularly see it working. But at least some of the time, it doesn't. I observed it failing to work this evening; details below.

I think the next step for debugging this issue is: keep an eye out for the symptom, and if you see it happen then try to get promptly to a computer — like within a few minutes — to take a look at the log. It's likely there will be something telltale there, even on a release build; if one of us happens to catch it on a debug build, there will almost certainly be good information there.

Related issues

Detailed report

Specifically, earlier this evening I opened up the app after it was in the background, and for a long time it didn't recover a live event queue. I replied to a message, and the message didn't appear in the existing message list, but did appear when I navigated to another message list that should contain it — which is the telltale symptom of a lack of an event queue. (Given the absence of #465.)

I was at home, on wifi, and had no trouble loading web pages while sitting at the same spot before and after this.

I left the app open for a while, with the device unlocked on the table, because I was curious how long the situation would persist. It lasted for at least 20 minutes: I kept looking down at the screen occasionally to check, and it was still at the "Combined feed" message list and still didn't have the new message.

On the other hand it didn't last forever! A while after that, I looked and the new message had indeed appeared. I'm about 97% sure I hadn't done anything that would cause it to appear short of a restored event queue: didn't navigate out of the screen and back in, and didn't kill the app and restart. I have some doubt only because it seems strange that an issue would cause the app to take over 20 minutes to do this, and yet not just prevent it completely from succeeding.

Metadata

Metadata

Assignees

No one assigned

    Labels

    a-apiImplementing specific parts of the Zulip server APIa-syncEvent queue; retry; local echo; races

    Type

    No type

    Projects

    Status

    No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions