On Thu 2016-07-14 15:59:15 +0200, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> +    status = _notmuch_crypto_get_gmime_ctx_for_protocol (&(indexopts->crypto),
>> +							 protocol, &crypto_ctx);
>> +    if (status) {
>> +	_notmuch_database_log (notmuch, "Warning: setup failed for decrypting "
>> +			       "during indexing. (%d)\n", status);
>> +	status = notmuch_message_add_property (message, "index-decryption", "failure");
>> +	if (status)
>> +	    _notmuch_database_log (notmuch, "failed to add index-decryption "
>> +				   "property (%d)\n", status);
>> +	return;
>> +    }
>
> Currently the only correct usage of _notmuch_database_log is the
> following pattern
>
>           _notmuch_database_log (notmuch, "Cannot write to a read-only database.\n");
>           return NOTMUCH_STATUS_READ_ONLY_DATABASE;
>
> In particular, the log buffer is only one line, and the caller needs to
> know to retrieve it.
>
> I agree it's not ideal, but I doubt you want to delay your stuff in
> order to extend/fix the internal logging API.

I understand that the internal log is currently only a single line, but
following the usage pattern you describe isn't useful for this case.

What is your suggested fix?  a given message could have multiple parts,
some of which are decryptable and others of which are not.

It makes no sense to stop indexing a message just because one of the
parts failed to decrypt, so i'm not going to immediately return.

I'm willing to accept that only the last log message will make it out to
the caller, and i could track whether anything has been written to the
log and change the return value in that case.  would that be acceptable?

    --dkg