Negative unread message count

[bjorn3]

I got this after a rate limit due to scrolling down too fast. It doesn't go away now that the rate limit is over and I scroll down on the respective streams. #t-compiler/help is also stuck.

[bjorn3]

Also got a +1 stuck now without rate limit on a different instance.

[bjorn3]

Comparing the web and terminal version I see that there was a message that still shows up in the terminal version but not in the web version. I guess it was deleted.

[Ezio-Sarthak]

Thanks for reporting this high-priority issue! This is a known regression in the terminal client and addressed via issues #642 and #574. We're actually having a hard time reproducing the negative counts, as they seem to appear in unexpected times. It'd be nice if you came up with a way of reproducing it.

Re the +1 stuck bug, this is also known, and could potentially be fixed while resolving #646 (see also #997). This does seem to occur more often than the negative counts, as per my experience. Is this the case for you as well?

As always, feel free to hop into CZO for more discussion :)

[bjorn3]

I started using zulip-terminal the same day that I reported this issue. Since both positive and negative stuck counts have happened several times for me. Yesterday I even saw a -24. I think positive stuck counts happen more often than negative, but it is hard to say for sure as I only just started using it. I also just saw a duplicate message sent at exactly the same time. Yesterday it skipped deletion of a message from someone else.

[bjorn3]

I kind of fixed a stuck positive count. I went from zooming in to the topic that had the stuck count to all messages and then back to the topic. This put the "cursor" to I think the amount of stuck messages back from the end of the topic. Scrolling down eventually resulted in -1 at the last message.

[neiljp]

@bjorn3 Do you use other clients at the same time as ZT? This is definitely a case where counts can become out of sync.

[bjorn3]

I have the android app installed. I don't have any other clients open.

[neiljp]

The current code can have issues where a message has not been fetched in ZT but is read elsewhere (eg. mobile, webapp, other ZT, ...) so this may be expected right now. A fix is under discussion.

[neiljp]

I pushed a commit to the main branch today which addresses one part of this where events arriving mid-search may not update counts, but the point I mentioned above is still outstanding.

[JPTIZ]

The current code can have issues where a message has not been fetched in ZT but is read elsewhere (eg. mobile, webapp, other ZT, ...) so this may be expected right now. A fix is under discussion.

Adding to the discussion, the way I caught this bug was by receiving a message duplicated just like @bjorn3: someone sent the message once (a simple "haha"), but zulip-terminal showed twice (not sure if it received twice as well). By reading the two, the unread message count became -1 (probably by reading the same message twice, reducing 2 from 1 unread). Switching streams and going back removed the duplicated message, but kept the -1.