Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unread counts on unreads screen stop updating #2800

Closed
gnprice opened this issue Jul 12, 2018 · 1 comment
Closed

Unread counts on unreads screen stop updating #2800

gnprice opened this issue Jul 12, 2018 · 1 comment
Labels
a-data-sync Zulip's event system, event queues, staleness/liveness zz-in progress

Comments

@gnprice
Copy link
Member

gnprice commented Jul 12, 2018

This is a symptom I've been seeing occasionally for the past few weeks. When I started seeing it, I heard from other users who said they'd been seeing it for a long time.

Symptom: I open the app, after it's been in the background for a while. The unreads screen looks like a nice list of lots of unread messages... but I look closer and it's basically from sometime in the past. It has messages that I've read through the webapp, and it doesn't have other unreads I received recently.

My experience has been it just stays this way indefinitely. Just now, to pin it down: I left the app open and kept the screen on for over three minutes straight, with the unreads screen shown. It never changed.

Right now one of those unreads (which in reality I read hours ago) is a PM; the PM conversations screen, and the number over the "people" icon for the tab for that screen, are showing the same stale information as the unreads list.

If I navigate around, go to various narrows, etc., the narrows all work fine -- we get the latest messages. But the unread counts never update. The only way I've found to kick it is to force-kill the app and restart it.

I think this issue is one of the main drivers of demand for #2712 .

@gnprice gnprice self-assigned this Jul 20, 2018
@gnprice
Copy link
Member Author

gnprice commented Jul 20, 2018

Update: after I wrote up this issue last week, @borisyankov suggested a possible cause, and we studied the code together and spotted a bug that would cause this.

Specifically: when we come online after being in the background for a while and then try to ask the server what's happened in the interval, we'll get a response saying that queue doesn't exist, because the server timed out (by default, at 10 minutes) on keeping it around for us. We have some code intended to handle this case (in startEventPolling) and refresh from scratch when it happens -- but in fact, that error-handling code doesn't work. That would cause us to just keep retrying the poll on the event queue, never getting an answer.

I have a draft of a fix, which I'll polish up and send.

gnprice added a commit that referenced this issue Aug 2, 2018
When this code was refactored yesterday in 5075ff6 to make room to
add the `payload &&` condition, a bug was introduced that completely
broke it.  The result is we'll always decide `needsInitialFetch` is
false here... so we won't go fetch any updated data, and won't start
the event-polling loop.

The result is basically the same symptoms as #2800, though what's
going on inside is different (the event loop isn't running at all,
vs. running but just getting the same error again and again.)

Fix it by un-swapping the syntax for a destructuring assignment.
@gnprice gnprice added the a-data-sync Zulip's event system, event queues, staleness/liveness label Nov 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-data-sync Zulip's event system, event queues, staleness/liveness zz-in progress
Projects
None yet
Development

No branches or pull requests

2 participants