Thanks for a bug report. I suppose the error comes when you update your IMAPx account and this account has enabled filtering, and/or checking for junk messages. Maybe you have setup a real Junk (and/or Trash) folder for that account too?

I do not know what precisely could break here, but I'd guess that some of your filters moved the message away permanently and that caused its unavailability in the Inbox folder, thus later this error (which is truly supposed to be gone).

I'd appreciate any details, including set message filters and spam filtering software settings, together with some steps for a reproducer. Maybe a log from the IMAPx communication would help as well, to see what it did in the background (ideally if you'd have enabled only one account when capturing the log, otherwise the output could interleave and make it harder to read). Such log can be captured when the Evolution is run with a command like this:

   $ CAMEL_DEBUG=imapx:io,imapx:conman evolution &>log.txt

Please note that such log contains everything sent to the server and received back, including message content and folder list and so on. A good news is that it's not required to be uploaded complete, the interesting part will be only with the message for which the error happened. Like in your above comment, the interesting message is 58001, where the same UID will be in the log as well.

I used gnome-online-accounts to setup email accounts.
Only filtering I have enabled is server side, nothing specific inside evolution.
Editing account settings for each account, I have no special folder set for Trash or Junk, only for Drafts to use local (but I setup Drafts later, after this).
For spam settings, I don't have anything setup in evolution by me (if there is something which is default then I can check its settings), there is probably something on server side.

I can try enabling debug, and log everything, but biggest problem is this happens randomly, so it can take some time.

I'll leave NEEDINFO flag until I get something from log.

Thanks. Please check Edit->Preferences->Mail Preferences->Junk tab, there is shown what junk software should be used and so on. If I'm not mistaken, then the "Junk test" filter is used when a new mail message arrives. A similar junk filter can be used when you mark certain messages as Junk, or not-Junk, when leaving the folder. These changes call the junk filtering software to learn spam or ham.

Still didn't tried to get debug information, I need some time to do that, and do multiple email check to make it fail. Just want to say about Junk mail preferences

Check incoming messages for junk (is set) 
Check custom headers for junk (is set)
 X-Spam-Flag  YES (contains value)
 X-Spam-Level *****

Created attachment 298408 [details]
evo_debug_log

From the log:
the account is configured to open up to three concurrent connections to the server, with currently two connections opened. One connection (B) downloaded the message successfully, but meanwhile was asked the other connection (A) to download the same message (UID 71680).

This concurrent access probably caused the local cache file delete, with the former message download indicated by the error "Empty cache file".

I'll try to take care of this situation.

*** Bug 735433 has been marked as a duplicate of this bug. ***

*** Bug 739547 has been marked as a duplicate of this bug. ***

After further investigation: The problem can happen both when there are multiple connections turned on, and when there is only one connection enabled, but multiple requests to get the same message are are piled in a queue. The thing is that the queue with multiple requests is flushed at once, causing all waiting threads do the same thing.

I do not want to break current IMAPx too much, a super-correct change would be to switch from a per-IMAPXServer job queue to one global job queue and let the connection manager distribute the jobs among connections (IMAPXServer-s), but such change may have regressions, thus I'd rather wait with it for later and will do only some minor necessary changes, which may help at least partially.

I filled bug #745545 for the follow-up work on this. There still can happen the 'Empty Cache File' error, but I guess it'll be quite rare. I also made a change in the returned stream, which should avoid almost empty message preview (but the next message select showed a correct message body).

Created commit 687d1b1 in eds master (3.15.92+)

I reverted part of the commit 687d1b1 at commit 9d07508, because that part could cause deadlocks.

*** Bug 754935 has been marked as a duplicate of this bug. ***