K-9: Long read timeout makes it appear that the app has stopped working when the connection is closed

[bdantas]

Manual fetching in K-9 Mail should work whenever there is a network connection, regardless of whether there has been in change in the network since last fetch.

What actually happens is that if email is fetched and then there is any change in network connection, trying to fetch again just hangs for a long time (indefinitely?).

To reproduce:

1. Start fresh by swiping away K-9 Mail from Recent Applications
2. Make sure you have a network connection (e.g., home wifi)
3. Launch K-9 Mail by clicking on its icon
4. Fetch email. It will work normally.
5. Turn wifi off, then back on. Reconnect to same network you were on before.
6. Click on K-9 Mail icon (or choose it from Recent Applications)
7. Try fetching email. It just hangs and doesn't fetch any email.

My workaround for the time being is to always remove K-9 Mail from Recent Applications whenever I'm done working with it. Wife is not so keen on having to do this. We experience this often because, in order to save battery, wifi shuts off when device sleeps. Therefore, upon waking, the device has to re-connect to wifi...thus triggering this issue.

Is this a bug or is there a simple fix involving a change in settings?

Our environment:
K-9 Mail version: 5.207
Android version: LineageOS 14.1
Account type: IMAP

[philipwhiuk]

This doesn't happen on mainstream Android. Logs would useful - otherwise I'd write this off as an OS issue.

[bdantas]

Thanks, Philip.

I did each of the "to reproduce" steps above a minute apart, like this:
20:18 - I started K-9 Mail and successfully fetched email
20:19 - I opened phone's Settings, turned wifi off then back on, reconnected to same network
20:20 - I clicked on K-9 Mail (to bring it back into foreground) and tried to fetch email
20:20-20:21 - Nothing happens ("fetching" spinner just spins and spins)
20:21 - After a full minute doing nothing, K-9 Mail fetches my email

The debug log is here (lines 204-206 are probably the most informative):
https://pastebin.com/xG5fyEta

Does this suggest anything to you?

[philipwhiuk]

This is actually expected behaviour, although perhaps it's indicative of too long a timeout.

This is a bit interesting but irrelevant

07-30 20:18:01.553 I/k9      ( 6353): No connectivity, canceling check for com.fsck.k9
07-30 20:18:01.573 I/k9      ( 6353): Not scheduling pushers:  connectivity? true -- doBackground? false

This is where the behaviour is

07-30 20:20:03.547 V/k9      ( 6353): conn228030806>>> 8 NOOP
07-30 20:21:03.652 D/k9      ( 6353): Connecting to imap.fastmail.com as imap.fastmail.com/66.111.4.136

What happens here is we send a NOOP to check the connection is alive. We then wait to read the response. Our timeout here is 60 seconds.

After the timeout expires, we close the connection and re-open one (note that it's a fraction over 60 seconds) which then works fine and fetches the email.

Our connect timeout is 30 seconds, our read timeout is 60 seconds. I'm not sure what the methodology of picking those was - my initial suggestion is that maybe the read timeout should be more like 10 seconds

@cketti ? @Valodim ? Any thoughts?

[bdantas]

As a user, the read/NOOP timeout of 60 seconds feels extremely long--it made me think there was a bad setting in the app, my network, or the phone's OS. Barring any technical contraindications, a 5 second timeout would be much nicer.

[bdantas]

P.S. Philip, the interesting but irrelevant bit in the log is probably due to me taking away K-9 Mail's permission to run in the background--via LineageOS's Privacy Guard. This was one of my many failed attempts at solving this problem before opening this issue.

[Paviluf]

I have a same kind of problem. It happen in 3G when the app stay open and I want to refresh the messages some time after. I thought that the app was hanging indefinitely but as I learned in the bug report it reconnect itself after a minute. It will be great if it can reconnect itself more quickly.
Thanks !

[bdantas]

I found a workaround: Automatically killing the K-9 Mail app anytime network connection goes down. Unfortunately, it requires installing a gratis but proprietary app called Automate (com.llamalab.automate). After you have the app, you can download and import the flow I wrote to accomplish the automatic killing: http://files.dantas.airpost.net/public/K9kill.flo

[d-tamm]

I can confirm this (or at least a similar) behaviour: After not using the app for some hours (e.g. over night), fetching mails does nothing for a looong time (probably those 60 secs). To kick the fetching running, it helps to restart the app. It also helps to switch networks, e.g. by switching off and on Wifi.
I think 60 seconds is by far too long. 5 seconds as proposed above would be much more reasonable.
However, why do we at all need the NOOP? Can't the app try to connect to the server directly? I'm not aware of a similar timeout issue in other mail apps which fetch the mails instantly when the user checks for new mail manually.