Missing Session Data

[N1N74]

Steps to reproduce

1. Where are you starting? What can you see?

2. What do you click?
   May have happened after an unexpected shutdown but unsure.

3. More steps…
   No signout initiated.

Outcome

What did you expect?

Account to be logged in and working as before. No signout was initiated.

What happened instead?

Missing session data. Forcing log out.

Operating system

Windows 11

Application version

1.11.3.0

How did you install the app?

https://element.io/get-started#download

Homeserver

matrix.org

Will you send logs?

Yes

[konomikitten]

I got this problem today when using Element Desktop and it's happened twice I've now switched to using my web browser instead. It'd be nice if someone could look into this because until recently I'd never seen the problem before.

Operating System: Debian bookworm
Element version: 1.11.25

[konomikitten]

I'm confident after thinking a little that this is caused by the Message Search option. Toggling said option seems to crash element with:

traps: element-desktop[15506] trap int3 ip:556ee01e3d3f sp:7ffe67fb6f10 error:0 in element-desktop[556edc95e000+785e000]

If anyone sees this bug report make sure to turn off Message Search in Settings -> Security & Privacy -> Message Search.

[JokerGermany]

Same problem with Ubuntu MAte 22.04, send Error protocol data.

What i have done?
Shutdown the Computer and started it later...

[jahway603]

I also got this problem today when using Element Desktop. I've been using Element since it was Riot and have never seen this problem until recently.

Operating System: Arch Linux
Element version: 1.11.26

[t3chguy]

@jahway603 please report issues with community maintained packages to their maintainer.

[jahway603]

@t3chguy I'm reporting the same issue that the OP @N1N74 experienced on Windows 11 on Aug 21, 2022; that @konomikitten experienced 2 weeks ago on Debian bookworm; and that @JokerGermany experienced 2 weeks ago on Ubuntu Mate 22.04. The issue I'm having is no different since all four of us are using your same Github releases, as you can see here. This is a YOU issue and not a packaging issue.

[t3chguy]

@jahway603 that PKGBUILD literally applies patches and does the build itself. It uses a Github release, yes, that is just a signed tag.

[jahway603]

@t3chguy Element has been working perfectly fine until this latest release. This issue is proof that other people are having the same issue I'm experiencing, yet all using a different operating system. I find it disturbing that your approach is to default that it's magically not a you issue because I'm not running Windows 11, Debian, or Ubuntu. You can see from this commit that the only change between Element working perfectly fine and me having this issue is the source code coming here from Github, which is why I'm reporting this issue here.

If the Windows 11, Debian, & Ubuntu users here were all not having this same issue, and I was the original poster, then you would have closed my initial issue report with the same incorrect reasoning. Again, this is not a packaging issue or other people using other operating systems would not be having the same exact issue.

[t3chguy]

@jahway603 make up your mind then, is it affecting all versions or just this release? The original report is from over 6 months ago. The underlying data handling is delegated to chromium/electron, the modal shown in the OP is based on a signal from the underlying browser that your storage has been evicted.

[jahway603]

@t3chguy There are also 5 separate Issues you've closed as you claim they are duplicates of this Issue

[jahway603]

@jahway603 make up your mind then, is it affecting all versions or just this release? The original report is from over 6 months ago. The underlying data handling is delegated to chromium/electron, the modal shown in the OP is based on a signal from the underlying browser that your storage has been evicted.

I want to know the root cause and how we help everyone having this issue regardless of their OS. Isn't that why Issues exist - to solve them?

[foresto]

This happened to me today, after upgrading from v1.11.26 to v1.11.29 of the flatpak, which packages the binary from here:

https://packages.element.io/debian/pool/main/e/element-desktop/element-desktop_1.11.29_amd64.deb

(Yes, I am aware that the flatpak is unofficial, but given that it uses the official binary from element.io, combined with the fact that people using a variety of build and packaging systems are experiencing the same problem, it sure looks like an upstream bug. I am therefore reporting it here as a data point for troubleshooting.)

[JokerGermany]

Should be the Same Computer and Account like at the 18th March. Send protocoll data again

[Xiretza]

Just happened to me with 1.11.33 on Arch. I sent logs (using this issue URL), can I do anything else to help this get fixed?

[bessw]

Happened to me today on windows 10.
I've send the error logs.

[Biep]

Please thumb up this issue, to get more attention for it. I reported my instance as #1129.

[DemiMarie]

@t3chguy I suspect the actual problem is that the storage is being evicted. Due to end-to-end encryption, Element’s client-side storage is not a cache and cannot be regenerated from server-side state. This means that Element needs reliable storage that is guaranteed to not be evicted, ever. Obtaining this requires calling navigator.storage.persist().

[t3chguy]

@DemiMarie this is already called.

https://github.com/matrix-org/matrix-react-sdk/blob/76b7aa2d33dfb8b00e3253db4d89376dc4ef6d65/src/utils/StorageManager.ts#L41-L55

[DemiMarie]

@t3chguy Should matrix-react-sdk warn if storage cannot be persisted?

[Zocker1999NET]

Should matrix-react-sdk warn if storage cannot be persisted?

In case of the desktop version which is always executed in a predefined Electron environment, I think it should raise an error and quit if storage cannot be persisted as users will expect it to persist all data. This may ensure that the storage does not become suddenly unpersisted if something changes in Electron itself. In the browser variant, a warning may be better instead as IMO users may be aware that browser sessions might be suddenly destroyed.

[Taranchul]

Same thing happens on Kubuntu 22.04, but only on one of my machines, and so far only with its Element installation via apt. The other installations on the same machine via Flatpak and Snap didn't show this behaviour yet. It's very unnerving having to re-login and re-verify this one instance approx. once every week.

edit: What's notable is that when it happens, Element seems to also have forgotten all of its settings, e.g. the server and username and the sorting settings for the room lists (I always set them to "A-Z", and it reverts to "Activity" when the session data gets lost.

Does anyone know where the session data is stored in Elements apt installation on *buntu 22.04 so I could cron a daily backup?

[JokerGermany]

I have this for one user, too.

Does anyone know where the session data is stored in Elements apt installation on *buntu 22.04 so I could cron a daily backup?

https://github.com/JokerGermany/Matrix-Tipps#how-to-activate-labs-on-element

[InklingGirl]

my computer crashed & i got this, i don't want to sign out because i forget my passphrase

[JokerGermany]

Happened to me for the fist time today, too..

[JokerGermany]

Can't send an report:

[eugenr]

In which files are those encrypted message keys stored and can I copy&paste them from a system backup I have? I want to try to manually restore that missing session data, at least the keys..

I'm on Debian bookworm using Element Desktop from it's repo. Under XFCE4 desktop. I can see the files under ~/.config/Element but I can't tell which are the keys..

[leanneeliatra]

This issue is also occurring for me. I reported it here #1926

[konomikitten]

I'm retesting Element Desktop on GNOME, one thing that can cause this is if you remove one of the many xdg-desktop-portal-* packages. On my desktop running XFCE I accidentally removed xdg-desktop-portal-xapp which was what was allowing Element Desktop to encrypt and decrypt session data.

I don't believe this was the case for my issue when using Element Desktop on GNOME but it's something more technical users that are having this issue can check.

[leanneeliatra]

Has there been any movement on this I am completely without Jitsi and it is extremely disrupting for the whole team.
I have to keep making everyone move to zoom as Jitsi is also broken in browser.

[hexxone]

Same problem just happened for me on latest Element Version on Windows.

It says I dont have enough space when there are >40GB available on C: Disk ?
Is it a problem with being an Electron App or something?
Does the chrome instance uses the internal browser localstorage instead of disk storage?
If yes, thats extremely worrying.

If I hadnt exported my keys, now all of my chats would be gone.
Obviously a chat application when sending lots of files and images will collect a lot of files over the time.

This should be investigated with priority.
Otherwise Element can never become a mainstream chat replacement if too many chats will crash it.

[DemiMarie]

I suspect the problem is that browsers do not use enough calls to fsync() when updating on-disk databases, meaning that an OS crash at the wrong time can cause severe problems.

[Taranchul]

If I hadnt exported my keys, now all of my chats would be gone. Obviously a chat application when sending lots of files and images will collect a lot of files over the time.

Next to key exportaton, I can highly recommend having multiple Element instances installed on the same or, even better, on different devices that are verified with one another. This way, one of them can get lost and then restored via another verification with one of the intact instances. This saved me multiple times whenever Element did something desasterous which it does way too often. 😕

[hexxone]

I suspect the problem is that browsers do not use enough calls to fsync() when updating on-disk databases, meaning that an OS crash at the wrong time can cause severe problems.

Yeah I could see that being a problem, however this does not apply in my case. I forgot to mention that my PC didnt crash.
The only thing I did was awake it from standby, then after some minutes (maybe 5) of using it normally, I saw on my 2nd screen that Element had crashed & logged out. I wanted to send the report but I miss-clicked and closed the error dialog.

I just know it said the same thing as in the screenshot of the issue (but in german in my case).

[Biep]

On my Linux system Element Desktop crashes silently whenever (it seems) it runs out of ready memory. This has been the case for ages, and is still the case now (1.11.86). In the past that would sometimes lead to the Missing Session Data issue.
Other programs don't crash in such a case, but wait till they get more memory assigned, and then continue.