Element displays error that it failed to restore the session when the network is not yet connected when it launches

[bessw]

Steps to reproduce

1. disable your internet connection (in my case after booting, element launched before the network was connected)
2. element opens with error that it could not restore the session "Sitzungswiederherstellung fehlgeschlagen"
3. after a short time element loads my session behind the error screen
4. enable your internet connection
5. click into the empty space around the error message and it disappears
6. everything works again as expected
7. some reboots later it happens again.

Outcome

What did you expect?

A message that tells me that my internet is not connected

What happened instead?

A error screen appeared that suggests me to clear the storage and login again.

Operating system

Windows

Application version

Version von Element: 1.11.57
Krypto-Version: Olm 3.2.15

How did you install the app?

A long tim ago from the official website

Homeserver

local Synapse v1.99.0

Will you send logs?

Yes

[BillCarsonFr]

Step to reproduce:

Put a breakpoint in client.getVersions() wait for the process to reach that point, then switch to offline mode and wait.

looks like the errors bubbles up and is finally caught in LifeCycle#loadSession and at the end is handled by handleLoadSessionFailure

[BillCarsonFr]

Looks like there might be an issue with getVersions():
** Edited **

There are several places where version is called and could reject:

- In Lifecycle > restoreFromLocalStorage > await checkServerVersions()
- In ServerSupportUnstableFeatureController await this.client.isVersionSupported(this.stableVersion))

There are other places where it's check but there is some basic retries, like in DeviceListener > cli.isVersionSupported("v1.1")

Maybe there should be some global retry on getVersion, and also throw something specific to be checked against in handleLoadSessionFailure and show something else?
Given the nature of getVersion, we might want to retry forever on certain errors though

[richvdh]

I saw this this morning; my server was briefly returning 500s in response to /_matrix/client/versions requests.

I feel like this has been mis-traged. Clearly it's happening semi-frequently; and it's really, really bad because it encourages the user to throw away all their state.

[opusforlife2]

and it's really, really bad because it encourages the user to throw away all their state.

This would not have been much of a problem if dehydrated devices was a stable core feature of Element from the start. But we don't live in that parallel universe.

[Nils-Magnus]

Same issue like the original poster: Element was started during boot when Internet was not yet available due to a delayed starting VPN.
Version von Element: 1.11.58
Krypto-Version: Rust SDK 0.7.0 (691ec63), Vodozemac 0.5.0
Localization: German

Apparently there are only those two options available (clear stored data XOR send logs). I was expecting to find a "Cancel" button or the option to close the modal dialog with an "X".

Clicking on the surrounding main window helped, but that was very unintuitive.

The reasoning of the error condition should be improved, which now reads "We encountered a problem restoring your session." If this is due to lack of connectivity, it should be stated here ("can't restore session from server XYZ ...").

The mitigation plan currently proposes "close window and return to more recent version". Both advices are problematic:

1. UX suggests that there exactly two options (see above), and closing this window is none of it (even though it actually exists, by clicking into the main window).
2. "return to more recent version" is an underspecified action for me: How do I "return" to this more recent version? Should I upgrade? But why then "return"? What is actually "more recent"? How to "return" to that?

[richvdh]

@t3chguy suggests that maybe this was introduced by us awaiting a thing that was previously done in the background.

[dbkr]

Regressed in matrix-org/matrix-react-sdk#12154 which adds an await with no explanation.

[realtyem]

Is it possible that during this error another sync handler is started up? If so, then I think this is indirectly the cause of the recent presence load issue. When I saw this error, was I able to click the red button and then 'cancel' on the next window which allowed me to not have to sign out and back in, but did lead to the behavior I saw that lead me to connect the dots. Full client restart mitigated it back to normal.