[Bug]: User Presence Status not updating on Windows Desktop Client

[muratbayan]

Before you file a bug report

• I have checked the issue tracker and have not found an issue that matches the one I'm filing.
• This issue is not a troubleshooting question. Troubleshooting questions go here: https://forum.mattermost.com/c/trouble-shoot/16.
• This issue is not a feature request. You can request features and make product suggestions here: https://mattermost.com/suggestions/.
• This issue doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• This issue reproduces on the most recent stable version, or the most recent prerelease version of the Mattermost Desktop App.
• I have read the contribution guidelines.

Mattermost Desktop Version

5.4.0

Operating System

Windows 10

Mattermost Server Version

7.10

Steps to reproduce

• Install Mattermost Desktop application on a Windows 10 desktop
• Log on to a Mattermost instance
• Leave Mattermost open without any activity for 10 minutes (no other devices active for the user doing this)

Expected behavior

• User presence status automatically switches to Away after 5 minutes as described in the doc
• Locking the user session (in this case by removing the smart card from the workstation) should also change the user presence status

Observed behavior

• The user status does not switch to Away (either on the machine itself or when other users look for that user in Mattermost) after ten+ minutes
• Locking the user session (in this case by removing the smart card from the workstation) does not change the user status, users remain online all the time

Log Output

No specific logs available related to this

Additional Information

Discussion thread on the Community Server here

Skype for Business clients on the same workstations have the expected behaviour of switching the status to away/offline.
Issue does not occur via the webapp (Chrome)

Trying on personal Windows workstations does not reproduce the issue.

[devinbinnie]

JIRA ticket: https://mattermost.atlassian.net/browse/MM-54736

[laborb-sb]

I would like to add that I have recently had the same problem with multiple installations of the Mac app.
App version 5.9.0, server version 9.10.1.
No improvement with new installation, update, clear cache.
The status is correctly determined/displayed in the browser.
In the app, the user is always shown as offline after a reload.

[devinbinnie]

@laborb-sb As a sanity check, the user isn't set to Offline manually are they? If you manually set them to Online and refresh does the same issue occur?

[laborb-sb]

Correct.

• the user is NOT manually set to ‘offline’
• If the user manually changes to ‘online’, this setting will not survive a reload/restart
• If the user is online in parallel in the browser or an (iOS/Android) app, this is displayed correctly in the desktop app
• the error does NOT occur with all clients that are logged in to the server. I therefore assume that the problem is not with the server. Unfortunately, I cannot currently see any pattern in the client desktops.

[devinbinnie]

@laborb-sb Is it only one user that's affected? Or is this happening to multiple users?

[laborb-sb]

To multiple user, but not every user.
Let me try to get a more systematic overview.

[pborsutzki]

I am observing the same problem as @laborb-sb but on two different Windows 10 machines, since the upgrade to version 5.9.0. After starting the desktop client the user is offline. When setting it manually to online, then restarting the client the users presence will again be set to offline.

[pborsutzki]

Looks a bit like this issue (github) to me. I can also reproduce it in Firefox and Chrome. Sometimes the presence is online after login, but after one or two page reloads the user appears offline again.

[devinbinnie]

Looks a bit like this issue (github) to me. I can also reproduce it in Firefox and Chrome. Sometimes the presence is online after login, but after one or two page reloads the user appears offline again.

This is likely the case, that issue we'll be looking at in the coming months as part of an overview of the status system

[laborb-sb]

To multiple user, but not every user. Let me try to get a more systematic overview.

In a small survey, 10 out of 12 users told me that the online status is NOT set automatically. Two of them seem to have no problems.
The affected systems have different OS versions (Mac OS 11.2 to 14.6.1) and run on ARM or Intel. Mattermost app version 5.9.0 is used in all cases

But to note again: the use in the browser (Webapp) or iOS app works without errors.

[Canardlaquay]

I'm also using 5.9.0 on Windows, was doing some unrelated things in local, and found two bugs which I think could help troubleshooting this.

I believe part of the problem could be here:

desktop/src/main/preload/externalAPI.ts

Line 482 in ddecc42

ipcRenderer.on(USER_ACTIVITY_UPDATE, (event, userIsActive, isSystemEvent) => {

When it's called from

desktop/src/main/app/initialize.ts

Line 459 in ddecc42

ViewManager.sendToAllViews(USER_ACTIVITY_UPDATE, status.userIsActive, status.idleTime, status.isSystemEvent);

The wrong number of arguments is expected in the externalAPI.ts, the value of idleTime is used in place of isSystemEvent.
It should say ipcRenderer.on(USER_ACTIVITY_UPDATE, (event, userIsActive, idleTime, isSystemEvent).

I believe this could potentially trigger a status that would be considered as manually set. (as long as the idleTime > 0)

I wasn't able to reproduce it with my current local configuration, but with a remote server (with a reverse proxy), yes. I'm not sure if this is related, but I've seen that a lot of websockets are ending in error with the remote server (unexpected EOF), which doesn't happen with my local configuration. The websocket EOF would cause the offline status update to execute everytime the connection is dropped.

Hypothetically, I suppose that somehow the status cache returns an error, the code above incorrectly sets the status as manual, which causes this line to be executed:
https://github.com/mattermost/mattermost/blob/e0e0b57b8bc4afd95d7e97377aca1d67ed04a7c9/server/channels/app/platform/status.go#L388

I believe it could be a combination of 1+2, 2+3 or just 2, but I lack time to properly test it out right now.

Hopefully this helps!

[Canardlaquay]

I ended up having a deeper look into it. Server version is 9.11.1.

I think the user presence status is unstable in both the webapp (v9/v10 but not v10.1) and desktop app at the moment.

There is a race condition happening upon querying the user's status at two spots:

• When the user logs in and the WebSocket connection opens, their status is set to online and the result is sent to the WS through the status_changed event.
• When the Reset status modal popup gets displayed (autoResetStatus action in reset_status_modal.tsx), a http request is dispatched to get the user's current status (/api/v4/users/status/ids).

The bug appears when the response to the HTTP request departs before and arrives after the WS status_changed event with a returned status of offline and manual set to false.

Testing on the community.mattermost.com server (v10.1.0) with the reproduction steps below, the bug pops up but the user only remains as offline for a few seconds until there's another call to the endpoint mentioned above, done in the status_profile_polling.ts. It's a new 10.1 feature, so I believe upgrading would help with this problem.

Reproduction steps:

• Server/webapp should not be >= v10.1.0
• Make sure you killed all the other connections
• Log into the app (desktop or web)
• Click on the "Channels" button in the top left, wait for the dropdown to appear
• Click on "Channels" in that dropdown.
• The user status should be shown as offline.

It is also reproducible with Fiddler thanks to the AutoResponder feature with a high latency for this response (1000ms is enough usually).

The Reset status modal should probably just wait for the WS status_changed event instead of manually querying the status, but I unfortunately don't know React or the app well enough to reliably fix this, sorry.

Add the inconsistency of the USER_ACTIVITY_UPDATE event handling shown in my first message above, plus the fact sendStatusUpdate is never called in the UserActivityMonitor.ts unless isActive is true, and the away status won't come up in the desktop app. isSystemEvent is only used in the tests as well apparently but most likely shouldn't?

desktop/src/main/UserActivityMonitor.ts

Lines 120 to 125 in ddecc42

	if (isActive && (this.lastSetActive == null || now - this.lastSetActive >= this.config.statusUpdateThresholdMs)) {
	this.sendStatusUpdate(false);
	this.lastSetActive = now;
	} else if (!isActive) {
	delete this.lastSetActive;
	}

[devinbinnie]

Thanks for the additional insight @Canardlaquay! Going to add this to the JIRA ticket and investigate the race condition you've described.