Automatic reconnect on networking-down event?

[boooyu44]

Hi,

First of all, thank you for great app.

I'm using external proxy to tunnel all ElectronMail traffic. The proxy sometimes fails and sometimes just regular internet delivered by ISP goes down.

During such network outage, ElectronMail enters "Connection timed out" and error appears (https://i.imgur.com/VUSxwW7.png) When the network connection returns, it seems that ElectronMail does not automatically reconnect and session is stuck in timeout mode.

During situations like these, i'm convinced that my emails are being fetched in background and i will be notified when anything new arrives. However when networking dies it seems that ElectronMail enters some sort of "dead" state and will not reconnect even when network is back online.

Is it possible to do something about it so it automatically reconnects once networking is back? It seems that it takes a single failed connection from ElectronMail to ProtonMail servers, for ElectronMail to enter some sort of deadlock state and never return from this state, essentially making the app disabled - no matter if networking is online or is not.

This is the only reason why i cannot replace traditional email client with ElectronMail.

[vladimiry]

That blue page you posted the screenshot of is designed by @protonmail, same as the logic when to display that page. So this is an upstream issue, not meant to be solved by ElectronMail.

As for the ElectronMail app, the local store feature reacts to the offline/online events. There is 3 local store fetching iteration triggers:

• Passively listening for some requests triggered by @protonmail. This is what enables the reactive syncing.
• Detecting the "online" event. Syncing gets triggered in this case with 3 seconds delay, configurable manually via dbSyncingOnlineTriggerDelay value in the config.json file.
• Every 5 minutes (configurable manually, see dbSyncingIntervalTrigger value in the config.json file). This is a sort of backup trigger, not really necessary.

As you understand the local store logic only kicks in when the @protonmail page/client is loaded and you are signed into the account (the user session is valid). In your case the @protonmail page/client has not yet been fully loaded/initialized.

The workaround is to:

• Clicking the "refresh page" (you can see this link on the screenshot you posted). Yellow dot in the tray icon indicates that some accounts are not in the signed-in state.
• Setting up some account loading delay via the Login delay range (seconds) input located in the "Advanced settings" block on the account edit form. So you give your proxy stuff some time to settle.

[boooyu44]

Thank you for quick response i hope i understood it correctly.

Unfortunately that wouldn't solve the issue completely, and the issue can be caused by many things.

Imagine having VPN with killswitch enabled so when users boot computer user there's no internet connection. The users connects manually to VPN.

One can set "Login delay range" and guess correct value in seconds, when will user establish connection to VPN.
Will he connect instantly? Or with like 10 minutes of delay? Is using static delay values solution to main cause? I dont think so. User activity and behavior are dynamic.

First time the user will connect quickly.. but in such situation login delay range will have value too high. Another time, he'll connect with like 15 minutes delay.. again the app will require manual intervention.

My point is that this type of mail app shouldn't require manual intervention on connectivity issues, although i understand the limitations and appreciate the response. It should be more like run and forget, without using hardcoded timing settings

As this is only wrapper for protonmail, wouldn't it be possible to monitor connectivity somehow via implementing background worker thread and once state changes eventually attempt/re-attempt to login to protonmail (so the local store logic kicks in.)

[vladimiry]

The issue is that there is already implemented "wait until the network is available" scenario before the @ProtonMail page/client loading gets started. You can test it by switching off the network (completely), starting the app, and then the @ProtonMail page/client loading won't be started until you enable the network. So since the page loading in your case got started then the app detected the network as available. Currently, network detecting is implemented using web/browser capabilities, like navigator.onLine, online/offline events which normally works well but it appears that it's not sufficient solution for a case like yours.

So apparently to handle an issue like this the app has to ping some address/host. I think the "Advanced settings" settings block could get new input with the host to ping (opt-in feature). Then if this input is filled the app for this mail account does real ping instead of using navigator.onLine stuff. This is how it might look but I don't mark it "as planned" yet.

[boooyu44]

Thanks you. Obviously no demands as at the end it's free software.

Currently i'm using TOR for electronmail as a proxy and the issues with connectivity issues are primarily associated with it. The Tor is working as windows service using tor expert bundle

Basic setup is VPN software kicking in on boot, electronmail boots up too, tor service boots as well. So 3 autostarting apps. VPN has full killswitch (no internet connectivity at all even with no VPN)

There are many factors that might cause issues. Network going up/down might cause TOR service to get crazy too (there's some delay until TOR it is able to reestablish circuit). If TOR is down, then electron mail won't be able to connect.

In case if you ever want to look into it, that's the way how these inconvenience issues can be reproduced. Thanks once again and have a good day.