Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Desktop client loses keys when disk is full #4014

Closed
drue opened this issue May 24, 2017 · 17 comments
Closed

Desktop client loses keys when disk is full #4014

drue opened this issue May 24, 2017 · 17 comments
Labels
A-E2EE A-Storage Storage layer of the app, including IndexedDB, local storage, etc. O-Occasional Affects or can be seen by some users regularly or most users rarely S-Critical Prevents work, causes data loss and/or has no workaround T-Defect

Comments

@drue
Copy link

drue commented May 24, 2017

Description

I ran out of disk space and I believe I rebooted in a disk full condition in order to lose swap files. After reboot, I get #2996. I'm not sure if #3660 is related or if desktop uses a real file API where you can avoid writing to a file when there is no disk space.

Version information

  • OSX Desktop 0.9.9
@ara4n
Copy link
Member

ara4n commented May 24, 2017

We currently use the localStorage API to store key data; we're about to switch to indexeddb though. Both will likely fail if your disk fills however (although it shouldn't corrupt entirely, it's up to Chromium rather than us). However, once element-hq/element-meta#647 you should at least be able to re-request the missing keys from other devices (including the sender).

@t3chguy
Copy link
Member

t3chguy commented May 25, 2017

So I guess the same would happen in a browser?

@turt2live
Copy link
Member

Browser behaviour is to stop accepting new keys because it can't, leading to future messages being unable to decrypt. I've run into this failure mode many times on riot-web.

@t3chguy
Copy link
Member

t3chguy commented May 25, 2017

@turt2live so #2996?

@turt2live
Copy link
Member

yes, but I'm not sure how desktop behaves, or how the browser behaves when your disk is full tbh.

@lampholder lampholder added T-Defect S-Major Severely degrades major functionality or product features, with no satisfactory workaround P3 A-E2EE labels May 30, 2017
@lampholder
Copy link
Member

Assigning a high severity and a low priority to reflect that this is highly disruptive but should be solved by element-hq/element-meta#647 (rather than taking specific steps to handle diskfill)

@drue
Copy link
Author

drue commented May 5, 2018

I'm tired of waking up to "* Unable to decrypt: InvalidStateError: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing. **" which means I have to quit Riot, delete all of Riot's files, launch and login again, and ask everyone to resend the messages I missed. Riot taunts me with "Re-request encryption keys from your other devices." but that doesn't work because I don't have another device.

I use my computer and sometimes it runs out of disk space. You have to deal with it. If you are using a broken library you have to patch it or find something else. Nobody cares if Chrome is broken or whatever. All they think is "Riot is shit and so is my friend for convincing me to use it." So I can't recommend Riot to anyone at least until you fix this.

@axelsimon
Copy link
Contributor

For future reference and in hopes that it will be useful to others, here is how I got rid of this problem:

  1. Clear up some space in your home directory (which in all likelihood is on the filesystem that is running out of space)
  2. Quit Riot:
    1.. If running as a standalone app, close the app
    2.. If running as a browser tab, close the browser
  3. Restart Riot
    1.. Sart the standalone Riot app, or
    2.. Start your browser

My encrypted conversations were all back to normal.

@axelsimon
Copy link
Contributor

Furthermore, would it be possible to show something friendlier to users, to help them? The current message is pretty horrible (you can't read your correspondant's messages, which is bad and stressful and makes you wonder if you've done something wrong, and on top of that the message is super technical/jargon-y).

Can I suggest:

Sorry, there is no disk space left on your device, because of this Riot couldn't store the secret keys needed to decrypt the message. Please make some space by deleting some data and restart Riot.

@jryans jryans added the A-Storage Storage layer of the app, including IndexedDB, local storage, etc. label Jul 30, 2019
@t3chguy
Copy link
Member

t3chguy commented Apr 11, 2020

this should now be alleviated on the Desktop app and Firefox where we get Persistent Storage permissions, in Chrome it may/may not get the permissions.

@turt2live turt2live mentioned this issue Apr 27, 2020
@axelsimon
Copy link
Contributor

This just happened to me on the desktop app and unfortunately, nothing is improved compared to the situation described several years ago.

The exact same message is still the one shown:

Unable to decrypt: InvalidStateError: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing

That message should really be changed to something understandable by someone who doesn't have a PhD in databaseology.
How problematic would it be to just replace the current error message with the one i suggested in November 2018? Can there be another cause but lack of disk space for throwing "Unable to decrypt: InvalidStateError: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing"?

@jpeg2600
Copy link

I'll just add to the issue that it just occured to me. My disk got full and somebody I couldn't receive or send encrypted messages on Riot afterward, previous messages showed the same failed transaction message.

I didn't troubleshoot much. I restarted Riot and had access to the previous messages but couldn't send any. I just started a new encrypted room since it was a new server.

@dbkr dbkr added the O-Occasional Affects or can be seen by some users regularly or most users rarely label Oct 14, 2021
@ara4n ara4n added S-Critical Prevents work, causes data loss and/or has no workaround P1 and removed S-Major Severely degrades major functionality or product features, with no satisfactory workaround P3 labels Jun 27, 2022
@3nprob
Copy link
Contributor

3nprob commented Jul 9, 2022

@ara4n what prompted the change from P1to P3?

As it may not be clear: Element-desktop will still effectively fatally wipe existing local data/keys/history in the event of storage shortage. It seems prudent to me to prioritize doing what's possible to prevent this for keys, at least, maybe by taking another look at storage API guarantees.

@aaronraimist
Copy link
Collaborator

aaronraimist commented Jul 9, 2022

@3nprob you are reading that backwards. It went from P3 to P1.

(the P labels are not really used anymore, the S-Critical is the important one)

@3nprob
Copy link
Contributor

3nprob commented Jul 9, 2022

@aaronraimist sorry for the noise, my bad, should not comment before coffee.

@richvdh
Copy link
Member

richvdh commented Mar 15, 2023

this sounds like a duplicate of #14174 (which is more recent, but has a clearer description of the symptoms), unless anyone can clarify the difference?

@richvdh
Copy link
Member

richvdh commented Mar 16, 2023

Duplicate of #14174

@richvdh richvdh marked this as a duplicate of #14174 Mar 16, 2023
@richvdh richvdh closed this as completed Mar 16, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE A-Storage Storage layer of the app, including IndexedDB, local storage, etc. O-Occasional Affects or can be seen by some users regularly or most users rarely S-Critical Prevents work, causes data loss and/or has no workaround T-Defect
Projects
None yet
Development

No branches or pull requests