Failure to report send errors
Dear Gnus developers, (CCing notmuch, because their users can be affected too) When message-interactive is nil, message-send can falsely report success even when sending fails and there is no way for the user to learn about the failure, expect from angry peers complaining about not receiving replies. The function responsible for this problematic behavior is message-send-mail-with-sendmail. It works in two modes: interactive and non-interactive depending on the value of message-interactive. The problem happens in the non-interactive mode (which is not the default). It executes sendmail with -odb -oem, which means that delivery should happen in background and errors should be reported to the user via email. sendmail is executed via call-process-region called without BUFFER argument, meaning that the return value is always nil. If sendmail fails to execute at all, perhaps due to corrupted configuration file, neither the message nor any error email is ever sent, but the user sees false "Sending...done" message. I think that call-process-region should be always called with a BUFFER so that sendmail exit code is returned and communicated to the user. Best regards, -Michal ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bug: "no top level messages" crash on Zen email loops
On 2018-03-29 04:17:21, Olly Betts wrote: > On Mon, Mar 19, 2018 at 05:03:21PM -0300, David Bremner wrote: >> I can confirm this reproduces both the xapian-check and the notmuch-show >> error. Olly agrees that whatever notmuch is doing wrong, it shouldn't >> lead to a corrupted database > > There was a Xapian bug here, which I fixed on master last week and will > be fixed in 1.4.6. An honor. It's not every day you find a bug in a database software. ;) > If changes to a new database which didn't modify the termlist table were > committed, then a disk block which had been allocated to be the root > block in the termlist table was leaked (not used but not on the > freelist of blocks the table can recycle). This was largely harmless, > except that it was detected by Database::check() and caused an error. Hmm... but if I understand correctly, that's one part of the story: I could get that error and not have the problem with `notmuch show`. Does that *also* resolve the issue with email loops? A. -- Travail, du latin Tri Palium trois pieux, instrument de torture. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bug: "no top level messages" crash on Zen email loops
Antoine Beaupré writes: > Hmm... but if I understand correctly, that's one part of the story: I > could get that error and not have the problem with `notmuch show`. Does > that *also* resolve the issue with email loops? I don't think so, no. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bug: "no top level messages" crash on Zen email loops
On Thu, Mar 29, 2018 at 08:50:22AM -0400, Antoine Beaupré wrote: > On 2018-03-29 04:17:21, Olly Betts wrote: > > If changes to a new database which didn't modify the termlist table were > > committed, then a disk block which had been allocated to be the root > > block in the termlist table was leaked (not used but not on the > > freelist of blocks the table can recycle). This was largely harmless, > > except that it was detected by Database::check() and caused an error. > > Hmm... but if I understand correctly, that's one part of the story: I > could get that error and not have the problem with `notmuch show`. Does > that *also* resolve the issue with email loops? Yes, from what bremner said on IRC there's still a notmuch bug here. My reply was really just in the context of Xapian to note what the bug actually was and when the fix would appear (since bremner sent his message to both the notmuch and Xapian lists). Cheers, Olly ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
