nnimap-request-expire-articles bug? (Was Re: nnimap, expiry-target, nnmail-fancy-expiry-targets)

["Davide G. M. Salvetti" <salve@icube.it>]

[NB: it seems that messages sent to ding@gnus.org disappear (it happened
thrice to me).  Posting through news.gnus.org appears to work, though.

I've changed the Subject line, due to the fact that I suspect
nnimap-request-expire-articles being the cause of this problem.  More
about it near the end of this message.]

>>>>> "NK" == Nevin Kapur <nevin@jhu.edu> writes:

NK> "Davide G. M. Salvetti" <salve@debian.org> writes:

>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>> string-match(".*" nil)
NK>                  ^^^
NK> Bizarre. This implies that one of the articles that you were trying to
NK> expire did not have a From header.  Is that true?

No, at least AFAIK.

NK> [...]

>> 1737 UID FETCH 3 BODY.PEEK[]
>> 1737 OK UID FETCH completed
>> <======================================================================>
>> 
>> (note 1737 here above).

NK> Unfortunately, me neither.  When I wrote the fancy expiry stuff, I
NK> relied on message-fetch-field to find the header to match against.

What I think is happening here is that the IMAP request #1737 doesn't
get the reply Gnus is expecting.  Gnus expect an article (cfr. IMAP
request #1732 in my <87sn2fiznh.fsf@hal.Olympus.INVALID>), but it gets
nothing at all (I guess if an article was to be sent there, it should
have been sandwiched in the middle of the #1737 request and the #1737
answer).

NK> If it's true that the message in question does not have a From
NK> header,

I think this condition shouldn't happen, as a From field in the header
is necessary indeed (AFAIK, I've not re-checked any RFC).

NK> then I guess we should decide on the right behavior.  Certainly an
NK> error is not the right behavior!

NK> If the message does have a from header, could you run

NK> M-: (message-fetch-field "from")

NK> on it and see if you get something non-nil?

While trying to follow your suggestion, I think I've tracked down the
bug, at least a bit.  Since I needed to know what message corresponded
to UID 3, I browsed the INBOX folder literally, and found that the UID
is recorded in a special X-UID field (on the IMAP server).  Well, the
fact is that no message corresponds to UID 3.

I don't know enough of the IMAP protocol to say if giving a completely
empty message in response to a request for an not existing message is
correct.  Regardless of it, the real question turns out to be: why is
Gnus requesting a non existing message?

So I found that gnus-request-expire-articles is passed a list of
expirable articles which possibly contains no longer existent articles:
since this is a totally-expirable group, it is passed
(gnus-list-of-read-articles group), by gnus-group-expire-articles-1:
according to the source this means active articles minus unread articles
minus dormant articles minus tick marked; the thesis follow since active
articles include deleted articles in between.

When nnimap-request-expire-articles receives this list, it doesn't
subtract non existing articles (contrary to what, say,
nnml-request-expire-articles do), and does the whole list.

Since we have an expiry-target in this group, nnmail-expiry-target-group
gets called in the (possibly empty because no such article exists)
buffer which results from nnimap-request-article, for each (possibly non
existent) article in the list.

In our situation nnmail-expiry-target-group calls
nnmail-fancy-expiry-target, which barfs because it can't find any
"From", "To", "Date", ... in the sadly empty buffer which resulted from
the non existent article request.

I think that nnimap-request-expire-articles should be fixed to subtract
non existing articles before doing the list.  I'd fix it, but at this
moment I don't know how to open the right holes (corresponding to
deleted articles) in the list.

-- 
Salve, | GNU PG (GPG) Key ID: 9396865D
Davide | <http://www.linux.it/~salve/>