You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We migrated a production Mattermost instance between data centres earlier today.
During the downtime period we intentionally took both source and target instances offline (so users would receive a 503 error) to avoid skew between the two installations during the sync.
Prior to and during this period, DNS TTL was reduce to 60s.
Once migration was complete, we restored service on the target instance but intentionally kept the source instance offline.
Connecting to the service via web browser worked fine at this point, but trying to use the already-running mattermost-desktop snap just showed 503 errors, confirmed by several users.
We tried logging out and logging in again, but this didn't make any difference.
It appears that the app does a DNS lookup on startup and then caches that result for far longer than expected, possibly indefinitely.
Fully stopping and relaunching the app resolved the problem.
What should have happened?
The app should have noticed that the target IP changed, and attempted to reconnect to the new target.
If not immediately, then certainly at the logout/login step.
Output of snap info $snap_name
name: mattermost-desktop
summary: Open source, private cloud Slack-alternative
publisher: Snapcrafters✪
store-url: https://snapcraft.io/mattermost-desktop
contact: https://github.com/snapcrafters/mattermost-desktop/issues
license: unset
description: |
Mattermost is secure workplace messaging from behind your firewall.
- Discuss topics in private groups, one-to-one or team-wide
- Easily share and view image files
- Connect in-house systems with webhooks and Slack-compatible integrations
To use this app, you need a URL for a Mattermost server.
-------
Host your own server: https://about.mattermost.com/download
Terms of Service: http://about.mattermost.com/terms/
Contribute to the project: https://github.com/mattermost/desktop
This snap is maintained by the Snapcrafters community, and is not necessarily endorsed or
officially maintained by the upstream developers.
commands:
- mattermost-desktop
snap-id: ed0pxJoDHrgmAWHH7baX5nryAHy1UNj0
tracking: latest/candidate
refresh-date: 6 days ago, at 21:22 +07
channels:
latest/stable: 5.4.0 2023-06-22 (644) 111MB -
latest/candidate: 5.5.0 2023-09-21 (687) 114MB -
latest/beta: ↑
latest/edge: 5.5.0 2023-09-22 (689) 114MB -
installed: 5.5.0 (687) 114MB -
This sounds like an upstream issue for the matter most desktop application
itself.
This bugtracker is for the snap package. Can you reopen it in the
mattermost desktop repo of the mattermost organization?
Thanks!
What happened?
We migrated a production Mattermost instance between data centres earlier today.
During the downtime period we intentionally took both source and target instances offline (so users would receive a 503 error) to avoid skew between the two installations during the sync.
Prior to and during this period, DNS TTL was reduce to 60s.
Once migration was complete, we restored service on the target instance but intentionally kept the source instance offline.
Connecting to the service via web browser worked fine at this point, but trying to use the already-running mattermost-desktop snap just showed 503 errors, confirmed by several users.
We tried logging out and logging in again, but this didn't make any difference.
It appears that the app does a DNS lookup on startup and then caches that result for far longer than expected, possibly indefinitely.
Fully stopping and relaunching the app resolved the problem.
What should have happened?
The app should have noticed that the target IP changed, and attempted to reconnect to the new target.
If not immediately, then certainly at the logout/login step.
Output of
snap info $snap_name
Output of
snap connections $snap_name
Output of
snap version
Relevant log output
No response
Teminal output of app
No response
The text was updated successfully, but these errors were encountered: