unreceived DM, sync issues

[dotmacro]

Problem

Another user sent me a DM, but I didn't receive it. There was no notification and no red badge.

The chat was empty, with no alert about connection issues or syncing. There was a grey spinner that kept spinning and spinning.

When I went to check the application logs, new entries kept coming in.

ScreenRecording_12-01-2025.18-05-28_1.copy.mov

This was on mobile, iOS 18, Safari PWA. No issues on other device.

Solution

Investigate, pinpoint the issue

[corrideat]

A few questions:

1. What's the chatroom ID? Normally, you'd find this in the URL, like https://groupincome.app/app/group-chat/chatroom-id-goes-here. You may send this as a DM if you'd prefer, since it's semi-sensitive.
2. You say: 'No issues on other device.' What does this mean, exactly? I'm guessing that it means that you can see the message fine on other devices, but please confirm.

I may have some other questions.

[dotmacro]

1. Confirmed via DM.
2. Yes, I could see the message just fine on the other device.

[corrideat]

@dotmacro Thanks. Some follow up questions, since the issue seems to have resolved itself now:

1. Was this a persistent issue until it started working? In other words, were you able to reproduce this behaviour of messages not loading, or did it only happen once?
2. Did it only happen for this specific DM? In other words, did you try loading other chatrooms and DMs, and did they work?
3. When it started working, did you get a red badge and notifications? (I'm guessing not, since you read the message on a different device). Should you have got a red badge and a notification on the iOS PWA? (What I'm saying is that maybe the reason you didn't get it in the iOS PWA is because you read the message on a different device first, maybe?)
4. Did anything change other than your force-closing the PWA when it started working? For example, did the other user or you post a new message to the DM?

[dotmacro]

1. Yes, it was a persistent issue. I knew I should have received a DM, so I tried a few different times to view it, and the app behaved the same each time.
2. I've never noticed this exact behavior before, but I also don't receive many DMs that I attempt to check first on mobile.
3. I never saw a red badge or notification. I didn't expect to see one on mobile, because by the time I had it working, I'd already checked everything on another device.
4. I force-closed the PWA, restarted my device, checked DMs on another device, and then waited about 5mins for everything to load. (This time it did say "loading" and "syncing")

[corrideat]

Thanks! As this was happening, was it only this specific DM that wasn't working? For example, were you able to check the #general chatroom or other DMs?

[corrideat]

Based on this image here and the rendering behaviour I've observed, it seems like this has happened due to ephemeral.messagesInitiated not being true:

[corrideat]

I'm still waiting to confirm which spinner is being displayed: whether it is the one that appears when ephemeral.messagesInitiated is falsy, or the loadingUp / loadingDown spinners. Based on how the app renders on iOS, it looks like in this case it's ephemeral.messagesInitiated being falsy, instead of loadingUp / loadingDown being truthy (those would render slightly above the position in this picture, at about 50% more the height of the red square).

Either way, this behaviour is perplexing. Going with the theory of ephemeral.messagesInitiated being falsy, the most plausible explanation is that at some point the call to this.chatroomHasSwitchedFrom(chatroomID) returns true. I considered the alternative that an error might be thrown somewhere, but that should result in an error being logged (the logs don't show any errors for this contract) plus a Failed to initialize chatroom prompt.

If this.chatroomHasSwitchedFrom(chatroomID) somehow is true, then I'm able to reproduce what happens here. For example, see mounted:

    if (this.summary.chatRoomID) {
      this.ephemeral.chatroomIdToSwitchTo = this.summary.chatRoomID
      this.processChatroomSwitch()
    }

If this.summary.chatRoomID is falsy, then I'm able to reproduce this behaviour exactly. However, note that this only affects mounted; hence, if this situation should arise, then manually switching to a different chatroom should fix this issue, at least assuming that this action sets this.summary.chatRoomID. I don't know whether @dotmacro tried switching to a different chatroom (although the response to this question hints that @dotmacro doesn't remember exactly). If switching was attempted, then it might be an issue with this.summary.chatRoomID not being properly set / updated / reacted to. Another possibility regarding this.chatroomHasSwitchedFrom(chatroomID) is that this.ephemeral.renderingChatRoomId somehow gets out of sync with chatroomID, but, after reviewing the logic in ChatMain, this seems quite unlikely, since this is only set in two locations (skeletonState sets it to null and is always called before the next place, processChatroomSwitch, which sets it to this.ephemeral.chatroomIdToSwitchTo).

In summary, what seems most likely based on what I observe here is that there's some issue with this.summary.chatRoomID, for example it being falsy, either 'persistently' or when the chatroom is mounted.

Another possibility is that one of the loadingUp / loadingDown spinners is being shown, but that doesn't seem consistent with what's being shown here, because, apart from the position of the spinner not being consistent with that, likely that would also result in the spinner disappearing after a short while (there are finally blocks to handle this) or at least in a 'flashing' spinner (i.e., appearing and disappearing).

[taoeffect]

What about this part of the story:

There was no notification and no red badge.

How does that fit in? Could there be another issue deeper in Chelonia?

[corrideat]

How does that fit in? Could there be another issue deeper in Chelonia?

Not sure exactly where that fits in (ChatMain rendering and notifications are independent from each other, although there could be a common root cause), but you're right it could indicate a deeper issue. Something that'd be consistent with what we're observing here while rendering and no notifications would be the server connection somehow being disrupted (although then we might see some other brokenness).

For example, this is what I see if I 'blackhole' the server port after loading the app:

So, I guess something that could also be consistent with what's happening is a spotty connection with the server.

ETA: I then tried restoring the server and manually unregistering the SW. That did remove the top banner and left the screen on the same state as shown here. That's also consistent with the logs, since I don't see any chatroom-specific errors when this happens. However, if this is what's happened, switching to a different chatroom / reopening the chatroom should resolve the issue. What's clear from all of this, however, is that we need to better handle spotty connections, either through error reporting or through retries.