Messages not showing until quit+reopen app

[brynwhyman]

I confirm (by marking "x" in the [ ] below: [x]):

• This is not a troubleshooting question. Troubleshooting questions go here: https://docs.mattermost.com/install/troubleshooting.html.
• (Maybe - hard to recreate) This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• I have read contributing guidelines.

---

Summary
Almost every 1-2 days, I and other users in my organisation do not receive sent direct messages (maybe tags in channels too). Quitting the desktop application and re-opening it will then show unread messages that were previously not visible.

Environment

• Operating System: Reported MacOS Monterey; Windows 10; Linux
• Mattermost Desktop App version: 5.1.0
• Mattermost Server version: 6.7.0

Steps to reproduce

1. Have someone send you a direct message (possibly it only occurs with 3+ people in the DM)

Expected behavior

1. The recipient sees a new unread message

Observed behavior

1. (Often but not always) The recipient does not see the new message in the MM app. Quitting and re-opening the app will then show the new messages.

Other notes
Of course I'm not sure how this is happening but to state the obvious, it's incredibly frustrating!

[amyblais]

@brynwhyman Do you see any errors in the desktop app logs?

[brynwhyman]

Hey @amyblais, this happened to me in the past two days. There has not been any errors (or anything for that matter) logged in ~/Library/Logs/Mattermost/main.log during that time.

[brynwhyman]

Just received another report from a staff member that this is happening on their Linux machine too. So I've added that to the description if that's helpful...

[brynwhyman]

Ah, sorry, I'd also add that the same issue appeared to have also occurred where someone was added to a new channel and was tagged. In this case, the new channel did not show for the user until an app restart.

[amyblais]

Tagging @devinbinnie here if he has additional thoughts for debugging this.

[devinbinnie]

@brynwhyman On Mac, which distribution are you using? If you're using MAS, the logs will be in ~/Library/Containers/Mattermost.Desktop/Data/Library/Logs/Mattermost

[brynwhyman]

Thanks @devinbinnie, there seems to be some more relevant log messages there. The logging starts after a force quit:

[2022-06-27 08:16:52.686] [warn]  main window closed
[2022-06-27 08:16:56.086] [info]  Log level set to: info
[2022-06-27 08:16:56.098] [info]  Log level set to: info
[2022-06-27 08:16:56.102] [warn]  Current working directory is /Users/<...>/Library/Containers/Mattermost.Desktop/Data, changing into /Applications/Mattermost.app/Contents/MacOS
[2022-06-27 08:16:56.253] [info]  Autoupgrade disabled: false
[2022-06-27 08:16:56.340] [info]  BrowserView created for server <domain>___TAB_MESSAGING
[2022-06-27 08:16:56.345] [info]  [<domain>___TAB_MESS...] Loading https://messenger.<domain>.com/
[2022-06-27 08:16:56.351] [warn]  couldn't show <domain>___TAB_MESSAGING, not ready
[2022-06-27 08:16:56.696] [info]  Can't send reload-config, will retry
[2022-06-27 08:16:56.697] [info]  Log level set to: info
[2022-06-27 08:16:56.745] [info]  Can't send enter-full-screen, will retry
[2022-06-27 08:16:56.884] [info]  [<domain>___TAB_MESS...] finished loading https://messenger.<domain>.com/
[2022-06-27 08:16:56.904] [info]  Can't send load_success, will retry
[2022-06-27 08:16:56.910] [info]  Can't send update_mentions, will retry
[2022-06-27 08:17:00.914] [info]  <domain>___TAB_MESSAGING timeout expired will show the browserview
[2022-06-27 19:53:47.942] [warn]  main window closed
[2022-06-27 19:59:25.332] [info]  Log level set to: info
[2022-06-27 19:59:25.345] [info]  Log level set to: info
[2022-06-27 19:59:25.348] [warn]  Current working directory is /Users/<...>/Library/Containers/Mattermost.Desktop/Data, changing into /Applications/Mattermost.app/Contents/MacOS
[2022-06-27 19:59:25.437] [info]  Autoupgrade disabled: false
[2022-06-27 19:59:25.494] [info]  BrowserView created for server <domain>___TAB_MESSAGING
[2022-06-27 19:59:25.497] [info]  [<domain>___TAB_MESS...] Loading https://messenger.<domain>.com/
[2022-06-27 19:59:25.500] [warn]  couldn't show <domain>___TAB_MESSAGING, not ready
[2022-06-27 19:59:25.902] [info]  Can't send enter-full-screen, will retry
[2022-06-27 19:59:25.934] [error] Error parsing server data from https://messenger.<domain>.com//api/v4/config/client?format=old
[2022-06-27 19:59:25.936] [error] Error parsing server data from https://messenger.<domain>.com//api/v4/config/client?format=old
[2022-06-27 19:59:25.938] [info]  Can't send reload-config, will retry
[2022-06-27 19:59:25.939] [info]  Log level set to: info
[2022-06-27 19:59:26.158] [info]  [<domain>___TAB_MESS...] finished loading https://messenger.<domain>.com/
[2022-06-27 19:59:30.163] [info]  <domain>___TAB_MESSAGING timeout expired will show the browserview
[2022-06-28 14:01:06.443] [warn]  main window closed
[2022-06-28 14:01:11.368] [info]  Log level set to: info
[2022-06-28 14:01:11.385] [info]  Log level set to: info
[2022-06-28 14:01:11.387] [warn]  Current working directory is /Users/<...>/Library/Containers/Mattermost.Desktop/Data, changing into /Applications/Mattermost.app/Contents/MacOS
[2022-06-28 14:01:11.485] [info]  Autoupgrade disabled: false
[2022-06-28 14:01:11.539] [info]  BrowserView created for server <domain>___TAB_MESSAGING
[2022-06-28 14:01:11.541] [info]  [<domain>___TAB_MESS...] Loading https://messenger.<domain>.com/
[2022-06-28 14:01:11.544] [warn]  couldn't show <domain>___TAB_MESSAGING, not ready
[2022-06-28 14:01:11.895] [info]  Can't send reload-config, will retry
[2022-06-28 14:01:11.896] [info]  Log level set to: info
[2022-06-28 14:01:11.960] [info]  Can't send enter-full-screen, will retry
[2022-06-28 14:01:12.092] [info]  [<domain>___TAB_MESS...] finished loading https://messenger.<domain>.com/

[brynwhyman]

Hello, do you have any further troubling shooting suggestion here? This is still happening to us!

[devinbinnie]

Sorry, must have lost track of this one. Unfortunately nothing in the logs seems to indicate an issue.
Can you first update to v5.1.1 to make sure it hasn't been resolved there? Next, turn on Debug logging in the Settings window, and that will spit out more verbose log messages which might better reveal an issue.

In your case, I would also recommended opening up the Developer Tools (View > Developer Tools for Current Server) and seeing if there are any error messages reported when a notification is received.

Thanks for your patience :)

[NilsHaldenwang]

I am also still having the issue on OS X Monterey 12.5 with Mattermost 5.1.1 as reported by the initial reporter.

[brynwhyman]

This is still happening to us. I'm really surprised this isn't reported more often.

I can confirm I'm on the latest version and this is still happening. I'm not sure there's any other action I can take at this stage.

Just noting another theory about reproduction steps too...

While it won't happen every time in these cases, it appears that when it does happen, it was a 'new conversation', so something like:

• the first time an individual sends you a private message
• the first time you are in a private message group with unique members
• you've been added to a new channel and tagged

[planet2bob]

I can also confirm this happens - particularly on the "new conversation" cases mentioned above. When being added to an existing or new group, I don't see messages until a refresh or for a couple hours.

Mattermost 5.2.2 on OS X Monterey 12.16.3

[devinbinnie]

Okay, so I'm wondering if this is being caused by the server itself. Has anyone tried to see if this happens for them in the browser as well? Or is the case that you only don't get notifications but when the app is open you do get mentions?

[michaelroa2]

I can also confirm this happens - particularly on the "new conversation" cases mentioned above. When being added to an existing or new group, I don't see messages until a refresh or for a couple hours.

Mattermost 5.2.2 on OS X Monterey 12.16.3

Apologies I'm not following the bug reporting procedure;
I'm having the same issues with the standalone client. New conversations fail to show in the direct messages section, at times I will have red message pending notification at the 'Channels' tab. I will try to investigate if it is mirrored in the web client, and see if I can create reproduce the bug with verbose logs.

Mattermost Version: 5.2.2.26057
Mattermost Cloud Version: cloud-2023-05-01-1
2019 Macbook Pro Ventura 13.3.1

[erlking]

same issue here, since a few updates (do not know which one though)
only error (or warning) i can find in desktop app log: [warn] couldn't show ___TAB_MESSAGING, not ready

my client: linux-flatpak Version 5.3.1 commit: 2c3d80f
colleagues facing the same issue with windows desktop app.

mattermost server: 7.10.0
Database Schema 105

never experienced that issue with the mobile app, only desktop app so far (win + linux)

[setpill]

I have managed to find a way to reproduce this systematically. It is caused by a network change between client and server. It applies to both desktop and web version.

1. Open two mattermost clients (e.g. desktop and web) that are connected to the same server.
2. Change your network connection. NB: not all network changes trigger this. For example, simply reconnecting did not trigger it for me, nor did switching from a wired connection to a connection tethered from my phone. What did trigger it was a change in my vpn connection (switching back to a legacy config or from there to the newer one). I suspect it's due to this changing my IP from the perspective of the server.
3. Refresh one of your clients (ctrl-r works on desktop)
4. See new messages and notifications come in on the refreshed client, but not on the non-refreshed client.

[devinbinnie]

I have managed to find a way to reproduce this systematically. It is caused by a network change between client and server. It applies to both desktop and web version.

1. Open two mattermost clients (e.g. desktop and web) that are connected to the same server.
2. Change your network connection. NB: not all network changes trigger this. For example, simply reconnecting did not trigger it for me, nor did switching from a wired connection to a connection tethered from my phone. What did trigger it was a change in my vpn connection (switching back to a legacy config or from there to the newer one). I suspect it's due to this changing my IP from the perspective of the server.
3. Refresh one of your clients (ctrl-r works on desktop)
4. See new messages and notifications come in on the refreshed client, but not on the non-refreshed client.

Based on this, it sounds like there's a disconnect in the websocket connection that isn't being reconnected quickly enough, or at all. @setpill If you can still reproduce this consistently, can you post a snapshot of your logs from the Developer Tools for Current Server (or the Chrome Dev Tools if it's webapp)? I'd like to see what the websocket behaviour is.

[setpill]

@devinbinnie What exactly do you want to see? Logs from the "console" tab in chromium dev tools? From the refreshed or non-refreshed client?

Assuming "console" tab in non-refreshed client - there's nothing new there after changing the connection.

[devinbinnie]

@devinbinnie What exactly do you want to see? Logs from the "console" tab in chromium dev tools? From the refreshed or non-refreshed client?

Assuming "console" tab in non-refreshed client - there's nothing new there after changing the connection.

Yes the "console" tab. Can you show me both? I'm guessing one websocket is reconnecting and the other isn't.

[setpill]

I'm not sure what there is to show... There's nothing new happening in the console tab after changing my connection. If I refresh, it would simply create a new websocket connection, no?

[setpill]

As in, I'm saying both console tab logs would look exactly the same... One simply has been done before the network change one after.

[devinbinnie]

Right, so what's supposed to happen is something like this:

Namely, the websocket should disconnect and then re-connect. This log is from community.mattermost.com. Are you able to reproduce on there? If so, do you get the same log output?

[setpill]

Interesting. No, I do not get a websocket closed line in the console when I trigger this with my own server. I will try to recreate on community.mattermost.com

[setpill]

I can confirm that I can reproduce this (browser client) on community.mattermost.com with the following steps:

1. Connect to community.mattermost.com with 2 clients (different browser tabs)
2. Create a DM to self
3. Open DM channel in both tabs
4. Change network (mobile tether to home wifi)
5. Refresh one of the tabs
6. Send "test" message in self-DM channel in refreshed tab
7. It does not show up in non-refreshed tab even after waiting several minutes

I also never see any websocket closed in the non-refreshed tab console.

[brynwhyman]

Hi MM team, just checking if more information is still required on this issue?

Even with the latest 5.4.0 release, this is still happening. I understand this is a difficult one to reproduce, but having messages intermittently not appear in a messaging app is a critical issue IMO.

Thanks for your help so far. Hopefully, we can get to the bottom of this.

[devinbinnie]

@brynwhyman Unfortunately we don't really have much to go on. I'm guessing this is more than likely an issue with some specific servers, but as said it's very difficult to reproduce which makes it hard for us to figure out what's happening.

We try to monitor issues around message reliability as closely as we can, so rest assured when we see issues we are looking at them. Apologies for the inconvenience.

[benno-sc]

Hi all, I'm experiencing this issue reliably at work. New group DMs only appear in the Mac app after restarting it, whereas they appear in the iOS app right away. I only restart the app on my Mac maybe once a week at most, so I only see those group DMs when it's too late to act. Maybe this helps to narrow down the issue.

[brynwhyman]

Sorry to come back to this...

I'm guessing this is more than likely an issue with some specific servers

@devinbinnie would it be helpful if we shared server information too? What would you be interested in?

[lifeofguenter]

We are experiencing this issue frequently as well:

Mattermost Version: 9.1.0
Database Schema Version: 113
Database: mysql

On various desktop clients. Mobile seems to be more reliable?

We definitely see this issue when our connection is being interrupted (VPN or switching WiFi), but we also see this on non-moving workstations.

[pejakm]

I can confirm the issue as well.

Mattermost Version: 9.0.1
Database Schema Version: 111
Database: postgres

Linux desktop client, happens when connection is interrupted, e.g. VPN, or switching WiFi, or device comes out of standby.

[matthewbirtch]

@devinbinnie should we open a Jira ticket for this? Seems to be ongoing