Message list loads forever when some messages have reactions #4156
Comments
|
Thanks @pohutukawa for the report! That is a pretty bad experience. One thing reported on #4033 was this workaround:
Does that fix it for you? That's still a bad experience -- maybe less terrible but still bad -- but it's potentially an informative clue for us in debugging it. |
gnprice
changed the title
|
Thanks @gnprice for taking this on. Yes, I have tried the force quit & reload, but it didn't work. I've also deleted all the cache & data of the app and re-connected to our Zulip server: Same thing, nothing loads. If I can help with gathering insights, I'm happy to provide them to my means of ability. |
|
@gnprice any further input on this? Anything we can do to provide further data to debug the problem? |
|
The loading view you're seeing is this one, right; gray squares and lines covering most of the screen?
Or is it a circular spinner, or something else? |
|
@chrisbobbe Yes, it's the "stripey one" in the screen shot above. |
|
Ping. |
|
@pohutukawa Thanks for your persistence with this! I think in order to get helpful logs for debugging this, we'll need to add some new code. I hope to have a beta version out soon with some code for that. If you haven't already, one step you can take now is to join the beta: A few other ideas that might turn up an interesting clue:
|
|
Oh, here's another idea: Do the affected streams all seem to have large files (e.g., images) in them? |
In steady state, these changes should be reverted or structured a bit better; it feels a bit haphazard. If the placeholders are still visible after 10 seconds, send a log to Sentry with all the events the WebView has received, with timestamps of receipt. Redact any `auth` fields by replacing the value with "redacted", and redact any `content` fields by extracting just the opening tag for the "message-loading" div so we can see if it has the "hidden" class. But we want to debug zulip#4156 ASAP, [1]: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/.23M4156.20Message.20List.20placeholders/near/921700
|
Here's an issue we haven't thought about in a while, but that's still open and a symptom is the gray bars showing indefinitely: #3281 IIUC, the theory there is that we fail silently and aren't retrying at all, and this particularly affects people with weak Internet connections by causing this symptom. Sounds very plausible, at least on the surface. @pohutukawa Is there anything consistent among you and your colleagues about your Internet connections, e.g., everyone's always on cellular data? (We should definitely fix this for users at all Internet speeds, but it might be a helpful debugging clue.) |
OK, I have just tried to connect to
If you look at my original entry in here, I did at one point upgrade our server to Git master due to a problem with the RabbitMQ queues getting the server repeatedly overloaded and stuck. So we're not quite in sync with published releases, even though on desktop/web clients everything works as expected. @chrisbobbe: |
Likely. Screen shots are very commonly used (unfortunately even where a text copy/paste would suffice). So I'd imagine the answer to your question is "yes likely". |
In steady state, these changes should be reverted or structured a bit better; it feels a bit haphazard. If the placeholders are still visible after 10 seconds, send a log to Sentry with all the events the WebView has received, with timestamps of receipt. Redact any `auth` fields by replacing the value with "redacted", and redact any `content` fields by extracting just the opening tag for the "message-loading" div so we can see if it has the "hidden" class. But we want to debug zulip#4156 ASAP, [1]: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/.23M4156.20Message.20List.20placeholders/near/921700
In steady state, these changes should be reverted or structured a bit better; it feels a bit haphazard. If the placeholders are still visible after 10 seconds, send a log to Sentry with all the events the WebView has received, with timestamps of receipt. Redact any `auth` fields by replacing the value with "redacted", and redact any `content` fields by extracting just the opening tag for the "message-loading" div so we can see if it has the "hidden" class. But we want to debug zulip#4156 ASAP, [1]: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/.23M4156.20Message.20List.20placeholders/near/921700
@pohutukawa Thanks. I have the same inference from that as you do -- it seems like the variable that triggers this bug is clearly something about your server, or perhaps about the data on it. Meanwhile, today I sent a new release to beta which adds some logging that should help us debug this: version 26.30.153. Please try out the beta: |
|
@gnprice Thanks for that. Just joined the beta and installed the new version (Android, 26.30.153). I have force killed and started the mobile Zulip client to make sure the new version is running. So far the behaviour is still identical (getting the "stripey" wait UI while loading without a change). If you'll let me know on how to access such logs to track down things further, I'd be glad to exercise this. Cheers for the assistance! |
|
Sentry issue: ZULIP-MOBILE-3SR |
|
Sentry issue: ZULIP-MOBILE-3SQ |
|
What is this sentry stuff up there? I don't seem to have any credentials to do anything with the links. |
|
We use Sentry for logging issues encountered in the app. Greg and I have access, and we've been debugging here. 🙂 One thing we've noticed is that there's something odd in the shape of the data representing reactions to messages, in the response your server gives to Do you know the Git commit ID of the server that's been running? There was a bug in handling that data, which was introduced in zulip/zulip@2a4c62a (committed May 19), and fixed in zulip/zulip@a53daa6 (committed May 21). You did say, at #4156 (comment), that you upgraded the server in the beginning of May, though, hmm. So you may never have been affected by this particular bug. Are you seeing weird things happening with reactions in the web app? The discussion that exposed the bug, on May 21st, was here. |
|
@pohutukawa We've done a bit more debugging, and I'm now pretty confident that that server bug is the one you're running into here. I recommend you upgrade the server to a current version. There's now a release candidate for Zulip Server 3.0, which perhaps has a somewhat reduced risk of having a really obnoxious bug like the one you unfortunately ran into with the version from Git you're currently using. Thanks again for your persistence in reporting and helping debug this issue. I think there are some things we can change that will make the effects of an issue like this one less painful in the future, and we plan to make those changes. |
|
I've just followed your I'll upgrade to the 3.0 RC next week and see how it goes. Cheers! |
OK, and that commit is indeed in the range @chrisbobbe identified at #4156 (comment) between when that server bug was introduced and fixed! So your server is indeed currently affected by that bug. When the bug was live on our development server chat.zulip.org, it was observed to cause these same symptoms. Closing this issue now because I believe we've completed debugging the issue, and the code is fixed in master. As I mentioned above, there are things we can change that will mitigate future issues like this one, and I've filed #4186 for the biggest of those. Do let us know how the upgrade goes, and if you run into new problems please let us know about those too. |
gnprice
changed the title
|
Just to confirm: Upgraded to the 3.0 version, and things are working again. Having said that, there was an issue where I had to do a Git upgrade to the 3.0 tag, as the "latest" tar-ball would lead to an error in the upgrade. There is also another issue as I wasn't able to use the data export before the upgrade or the Awesome @gnprice, much appreciated and thanks for an awesome open source software experience! |
|
Excellent. Thanks @pohutukawa for confirming, and for being an awesome bug reporter! Please do file that upgrade issue too (in zulip/zulip) -- we'll probably do a 3.1 release within the next couple of weeks, and this sort of upgrade issue is the perfect kind of thing to fix for that release. |
Unless visiting a stream with only very few (up to about a hand-full) messages, the mobile UI never loads the topic/message list. It remains in the stylised "message list loading" type of screen (fancy spinner). To me, this seems possibly related to #4033, but it may be different (more severe?).
In our environment pretty much all users experience this on the mobile Zulip client on both Android as well as iOS. The web and desktop clients all work fully as expected, with a very responsive UI.
Side note: After an issue with the RabbitMQ queue handling on the server (issue zulip/zulip#14862) at the time we have resolved to upgrading the server to the current Git master (beginning of May).
The text was updated successfully, but these errors were encountered: