[Feature Request] Ability to delete all emails

[CodeCracker-oss]

Hello,

The ability to delete all e-mail's from Proton account has been requested a lot from people over on reddit and Proton appears to be ignoring this issue. Is it possible for you to implement a unique to electronmail feature to delete all emails from the all mail folder? I backed up my e-mails, and as Proton only allows selecting 50 emails per page, with 25,000k+ emails, this would take hours. prior to around august 2022 deleting from all mail via thunderbird use to work, just CTRL+A plus delete, then empty trash. Now it just errors out, saying its not supported deleting from All Mail. For those on free plan with limited space, this is concerning.

If possible, would you consider adding such a feature?

Thank you

[vladimiry]

This should already be possible with the local store feature enabled for the account. Once the initial sync/bootstrap stage got completed (all emails got downloaded), you just select the "All Mails" folder and click remove button located in the top-right corner of the emails list. Removing emails from the local store interface is available since https://github.com/vladimiry/ElectronMail/releases/tag/v4.9.0.

I didn't try it in action for the "All Mails" folder, but for others. But since the app removes emails by individual IDs there should be no difference which folder is selected.

[CodeCracker-oss]

Ok, I can try that. For the past, i haven't had the local store option enabled. I didn't think it synced the changes made to local store with the server.

Would this be expected to take roughly as long as the orignal sync, or will it just send a request to Proton server to remove them? If possible, I was thinking more of having an Empty Folder button within the All Mail folder injected into the WebClient as if I have to enable Local Store, it will take some time to sync as many emails as I have.

[vladimiry]

I was thinking more of having an Empty Folder button

This has to be supported by the proton's backend/API and at the moment I'm not aware of such API. There is no publicly available API documentation as far as I know. So currently, the removing API call requires mails IDs parameter to be passed.

Bootstrap sync takes time as it loads not only the mails metadata which would technically be sufficient for mails removing purpose as IDs are there in the metadata, but also loads & decrypts the mails body/content data which involves individual API call for each mail.

[CodeCracker-oss]

This has to be supported by the proton's backend/API and at the moment I'm not aware of such API. There is no publicly available API documentation as far as I know. So currently, the removing API call requires mails IDs parameter to be passed.

That is actually what I was sort of expecting, though wasn't sure. I will try and request such a feature from proton again, it just appears to keep being ignored. I am currently syncing up with local store, once done I will test it and report back.

Thanks :)

[vladimiry]

The app currently chunks the IDs list to the portions of 150 size and then calls API for all those chunks in parallel. So technically there is a chance to face something like server rate limiting error if the built-in in the app rate limiting bypassing logic is not well polished. In this case, processing chunks in for in loop would be a simple fix.

https://github.com/vladimiry/ElectronMail/blob/25520bad3adb5e57a047de7f96d1ec3e4bf9b174/src/electron-preload/webview/primary/provider-api/index.ts#L159-L166

[CodeCracker-oss]

The app currently chunks the IDs list to the portions of 150 size and then calls API for all those chunks in parallel. So technically there is a chance to face something like server rate limiting error if the built-in in the app rate limiting bypassing logic is not well polished. In this case, processing chunks in for in loop would be a simple fix.

I had just tried deleting everything from All Mail (10923) and after 10 seconds or so it gave error "Request timed out". Afterwards, couldn't try again until I restarted Electronmail. I did verify that it did indeed delete a lot in that short time though. I seen in the All Mail folder it dropped from 163pages to 128. 2nd attempt it gone down from 128pages to 13 before the request timeout error appeared again. 3rd time was a success without error appearing at all.

So it does work. Is the request timeout error linked to the server rate limiting error you were referring to?

[vladimiry]

Thanks for the report.

Is the request timeout error linked to the server rate limiting error you were referring to?

It doesn't look like rate limiting error, so currently implement rate limiting workaround in the app appears helpful.

The timeout you faced is likely set by the client side of the app (hardcoded one minute value). If so, you could just wait more ignoring the error message and then after restart everything would be dropped. I think I should increase that timeout like 10x or drop it completely (easy fix either way). The timeout in the first place introduced to simplify issues detecting.

[vladimiry]

drop it completely

Done in https://github.com/vladimiry/ElectronMail/commit/c95e765ceee20719ab855e7419434398e342c700. Closing as improved.

[vladimiry]

after 10 seconds or so it gave error "Request timed out".

The timeout you faced is likely set by the client side of the app (hardcoded one minute value).

It doesn't look like rate limiting error, so currently implement rate limiting workaround in the app appears helpful.

One correction. It doesn't look like it's a client timeout set by the app, as it's one minute (hardcoded) vs named 10 seconds. So then it might be a network timeout. @dhammel can you post related lines from the log file?

processing chunks in for in loop would be a simple fix.

Considering switch to for in processing.

[CodeCracker-oss]

So then it might be a network timeout

I was actually getting a network error in Proton Drive, if it has any relation. When uploading multiple 2GB files, it would error out at around 1GB and say Network error. It worked at drive.proton.me however.

can you post related lines from the log file?

I believe I copied everything in relation to this error https://pastebin.com/JPTWCJDX

Considering switch to for in processing.

How would I do this?

[vladimiry]

Thanks. This indeed looks like network request timeout.

How would I do this?

This is a code-based change. So instead of triggering multiple request in parallel, I will be switching to sequential requests process. This should greatly reduce a chance for that network request timeout to happen.

[vladimiry]

So instead of triggering multiple request in parallel, I will be switching to sequential requests process.

Might be working slower, but stability should be improved by https://github.com/vladimiry/ElectronMail/commit/f1e8830de9f16136ba96b6d3842ed6c828985af3.

[CodeCracker-oss]

@vladimiry I just noticed, as I opened up Electronmail today, that the local store wasn't syncing, it appeared as if it was but wasn't downloading anything at all. The database.bin was the same file size as before I deleted All Mail, as if it deleted fron proton server ok, but didn't delete from local database (Even though it showed 0 messages under any folder) Simple fix, by just disabling local store, restarting app and re-enabling it. Doesn't look like expected behavior, so I thought I'd let you know.

[vladimiry]

@dhammel there is also database-session.bin and the intermediate changes come there until they get merged to the database.bin (when database-session.bin reaches 5MB size if I remember it right). This is done this way so a large primary database.bin doesn't get re-saved/crypted each time (performance matter). I think more merging triggers could be added in addition to 5MB size, like "deleted mails list" is not empty and "mails list" is empty. It won't make sense anyway when #571 gets resolved.

[CodeCracker-oss]

@vladimiry database-session.bin does normally fill up in active session, the way its always worked for me was everything would fill in that file, and get merged next restart of app during the "Loading Local Store" message. Although that didn't happen this time after 30 minutes.

[vladimiry]

5MB database-session.bin size trigger got added not long ago (one or few recent versions). Before that the merge was happening on every app restart like you described. This size trigger value is editable in config.json, so the original behavior can be returned by setting a very low dbMergeBytesFileSizeThreshold value (file size in bytes).