thunderbird / thunderbird-android

K-9 Mail – Open Source Email App for Android
https://k9mail.app/
Apache License 2.0
9.97k stars 2.47k forks source link

Don't retry failing uploads indefinitely #3986

Open muessjoeh opened 5 years ago

muessjoeh commented 5 years ago

Every 3 months or so I have a problem accessing my web.de account: When I activate the directory list (in German 'Ordnerliste'), I see that ever folder has an error message (the beginning is 'SSLException: Write error:'; how can I see the rest?). From now on, fetching the mails is approximately 10x slower, and storing changed mails (e.g. with a changed read status) is not working at all. The only solution that I know of is a fresh install, what of course repeats every 3 months.

cketti commented 5 years ago

Please fill out the issue template and record a debug log while refreshing the folder with the error. Also record a debug log while trying to mark a message as read.

muessjoeh commented 5 years ago

Strange, I wanted to produce the log file, some circumstances forced me to delay it, and today I see that this problem has vanished without any further interaction except fetching of emails. I found out in the meantime that only my web.de account was affected. But I am still curious what causes this problem, since it occurs regularly.

cketti commented 5 years ago

We'll reopen the issue when more information can be provided by someone affected by this.

chrisgee commented 5 years ago

I may be having the same issue as described here. Sent messages are not stored on the server (although they are shown in the local sent folder). Read status is not updated, etc.

Therefore I attach a log here. k9-log.txt

Environment

K-9 Mail version: version used is com.fsck.k9 version 5.600 as installed by f-droid.

Android version: 7.1.2

Account type (IMAP, POP3, WebDAV/Exchange): IMAP account

Please let me know if more information is needed

muessjoeh commented 5 years ago

Bad news: I was able to cope with that effect by (1) waiting a few days, or (2) reinstall k9mail. If you find a third way, please let me know!

Am 22. Juni 2019 11:35:32 MESZ schrieb chrisgee notifications@github.com:

I may be having the same issue as described here. Sent messages are not stored on the server (although they are shown in the local sent folder). Read status is not updated, etc.

Therefore I attach a log here. k9-log.txt

Environment

K-9 Mail version: version used is com.fsck.k9 version 5.600 as installed by f-droid.

Android version: 7.1.2

Account type (IMAP, POP3, WebDAV/Exchange): IMAP account

Please let me know if more information is needed

-- Public key at https://pgp.mit.edu/pks/lookup?op=get&search=0xD0E087F6E4D97FB7 or https://sks-keyservers.net/pks/lookup?op=get&search=0xD0E087F6E4D97FB7 Fingerprint: EDC8 6730 DCF1 1BFB 02AF 56D7 D0E0 87F6 E4D9 7FB7

tim-kiefer commented 5 years ago

I have the same problem: re-installed twice in the last two months. Now again, I see SSLException: write error in the folder list and BrokenPipe Exceptions in the log (as can be seen in the file chrisgee provided). I was unable to find a work around or solution other than a fresh install.

I also have K-9 v 5.600. Android is 8.0.0

cketti commented 5 years ago

@chrisgee: Thanks for the log. The message being uploaded is quite large. Chances are the server is closing the connection because it considers the message too large. Or maybe the quota is exceeded. Unfortunately, K-9 Mail considers this to be a temporary error and will try to upload the message over and over again. All other command wait in the queue until the upload command succeeds (or fails permanently; which, in this case, it never does). That explains why the read status is never updated.

chrisgee commented 5 years ago

Thanks for the info. I guess this should be considered a bug, namely that the failing task breaks a lot of other functionality.

Bzw, it's not my quota.

Any way to recovery without reinstalling and deleting all the not uploaded messages?

Thanks, Christoph

Am 29. Juni 2019 18:03:57 MESZ schrieb cketti notifications@github.com:

@chrisgee: Thanks for the log. The message being uploaded is quite large. Chances are the server is closing the connection because it considers the message too large. Or maybe the quota is exceeded. Unfortunately, K-9 Mail considers this to be a temporary error and will try to upload the message over and over again. All other command wait in the queue until the upload command succeeds (or fails permanently; which, in this case, it never does). That explains why the read status is never updated.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/k9mail/k-9/issues/3986#issuecomment-506967952

-- Christoph Gohle

muessjoeh commented 4 years ago

It also happened to me. After about 2 weeks or so the effect was gone. The reason why this effect is transient could for example be a mail that k9 does not like, that vanished after 2 weeks of the list. Or something completely different.

Here is the error log: k9-log.txt

chrisgee commented 4 years ago

Hey, i would be glad to see this fixed in future releases. Maybe you want to reopen the issue. Plesse let me know if you need more input... Although now I have reset my instance oft k9, so I may not be able to reprodue it any more. C.

muessjoeh commented 4 years ago

Yes, I would like to reopen this issue, but I do not know how this is done. Can you help me?

cketti commented 4 years ago

It's unclear how this situation should be handled best. A connection could be closed at any time without it being a permanent error. We could count the number of upload attempts and stop trying automatically after a certain amount of attempts. We already do this for send failures.

muessjoeh commented 4 years ago

How is this handled now? Are there any hints WHY this is happening every now and then?

chrisgee commented 4 years ago

I am quite ignorant with respect to what is going on in K9 internally. But I imagine the following:

If there is a list of commands to the server to be processed, wouldn't it make sense to just go through the list one by one (if there is no specific order required) and keep failed commands in queue until the next attempt. Also it would be very helpful if repeated failures would be reported to the user so that he may take a custom action on those? Like this commands without repeated failure could be processed and would not be blocked in the mean time...?

Just an idea...

muessjoeh commented 4 years ago

... but it sounds like a good one.