Re: [Evolution] Unable to retrieve message

[Milan Crha <mcrha redhat com>]

On Fri, 2020-01-10 at 14:17 +0000, Pete Biggs wrote:
> I wouldn't like to point fingers, but multiple Evo clients seem to
> work OK together ...

        Hi,
it depends. I recall there are cases where even one Evolution instance
can trick itself. If I recall correctly, it had something to do with
"Synchronize messages for offline use" and local filters. There
happened that the IMAPx provider noticed new messages in a folder and
piled a job to download all the new messages for offline use. At the
same time, or shortly afterwards, local filters had been triggered and
some/all new messages had been moved to their folders. And only after
this move operation the offline download started, realizing the new
messages are not there. You might recall "famous" "Empty cache file"
errors, which showed up quite often not long time ago. The servers I
worked with do not return error when one asks for a content of a
nonexistent message, it rather returns success, with no data
transferred to the caller. This made the cache file empty, because the
server did not return any data.

I do not recall how this had been fixed/worked around, it can be the
"Empty cache file" error is ignored for offline download.

To answer your question:
> > It feels like there is some miss-match of cache syncing policies
> > between devices - or something not checking for changes before
> > syncing. Does that sound possible to you?

Yes, it does sound possible. Updating local cache, even if only the
folder state, before every operation would make things very slow (at
least in some cases). That means that the only viable option is to make
the provider robust, to react on errors gracefully.

It sometimes feels that Evolution is too chatty with error messages. I
believe regular users do not want to see most/majority of them. I think
other clients hide some/few/many errors from the users, pretending
things worked properly (that's only my own guess). The thing is that I
personally prefer to see an error message than to wonder why some thing
should work, but it doesn't, without any clue. Again, that's only me,
others may have other opinion. From the coder's point of view, as the
code is right now, it's close to impossible to distinguish whether the
operation had been run by the user (in which case the error should be
shown always) or whether it was run as part of certain periodical
action (like check for new messages every hour). The second case might
not need to show the errors, it'll retry the next time on its own.

        Bye,
        Milan