GNOME Bugzilla – Bug 770457
Prevent GError pileup in CamelFolderSearch
Last modified: 2017-01-20 14:56:31 UTC
GErrors can pile up when running a CamelFolderSearch. See e.g. the following code: > for (i = 0; i < indexed->len && !g_cancellable_is_cancelled (cancellable); i++) { > const gchar *uid = g_ptr_array_index (indexed, i); > > if (match_words_message ( > search->folder, uid, words, > cancellable, error)) > g_ptr_array_add (matches, (gchar *) uid); > } match_words_message() returns a truth value, but the error state is never checked or cleared. This is the case in several places in camel-folder-search.c. It results in spew like the following: > (evolution:23334): camel-WARNING **: CamelStreamMem::read() set its GError > but then reported success > > (evolution:23334): camel-WARNING **: Error message was: Cannot get message > 1447686773.26237_210172.linux-ylfy.site from folder /home/hpj/.local/share > /evolution/mail/local/.Organizations.Copyleft Bonanza: Cannot get message > 1447686773.26237_210176.linux-ylfy.site from folder /home/hpj/.local/share > /evolution/mail/local/.Organizations.Copyleft Bonanza: Cannot get message > 1472164085.6848_250510.linux-vtz2 from folder /home/hpj/.local/share/evolution > /mail/local/.Organizations.Copyleft Bonanza: Cannot get message > 1472164084.6848_250509.linux-vtz2 from folder /home/hpj/.local/share/evolution > /mail/local/.Organizations.Copyleft Bonanza: No such file or directory Since the returned errors are never used for anything anyway, and a single missing message shouldn't stop the search IMO, just passing in NULL instead of an error pointer is a satisfactory (though not great) solution. A slightly better solution might be to distinguish between tolerable and fatal errors, and let the latter stop the search. But we'd have to agree on what the policy should be.
Created attachment 334247 [details] [review] 0001-Camel-Prevent-GError-pileup-in-CamelFolderSearch.patch Tentative fix.
Thanks for a bug report and the patch. I'm unsure about the change, to be honest. It can be a fatal error when the message cannot be opened, because the message might be picked as part of the final result, but because it's not available at the moment when the filter had been run, then it'll be missing in the final set, instead of the error being reported. Are there any tolerable errors? The only one I can think of is "not available in offline", which means the result will contain only those messages which are available in the offline mode and which satisfy the criteria. It's a pita that the API doesn't allow to return partial result and report a warning to UI, that some messages couldn't be considered for the search, because that would be an interesting improvement. The current API, as is, allows only returning either error or the result, but not both.
I changed my mind and made a similar (it has the same outcome) change within bug #777431, thus I mark this as a duplicate of it. *** This bug has been marked as a duplicate of bug 777431 ***