bug#36341: 27.0.50; Reading from the Gnus dribble file leaves data inconsistent

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>>> I'm pretty sure I just figured out what's wrong with the dribble file,
>>>> but I'm setting out on a 80-mile bike ride now, and will fix it
>>>> if/when I have survived that.
>>>
>>> Good luck!
>>
>> I survived!
>
> Yay!
>
>> But I'm having trouble reproducing this. Can you give me a more basic
>> recipe, like "mark some messages read, exit with `Q`, restart"?
>
> First save with `s' so you have a "known good state".  Then enter a
> group (that has some unread articles), mark everything as read (with
> `d'), `q' out of the group and then `Q' out of Emacs.  You should now
> have a dribble file.  Then say `M-x gnus' and answer `y' to the question
> about whether to read it.
>
> The group where you marked everything as read should now be displayed in
> the group buffer with the same number of unread articles as it had
> before you entered it the last time.

Man, this is killing me. I've narrowed it down to:

- If a dribble file is present, "g" (including gnus restart) ignores the
  dribble data, but "M-g" honors it. You can bounce back and forth
  between correct and incorrect unread counts by alternating "g" and
  "M-g".
- The dribble file is *only* eval'ed at startup time, which must
  mean that there are good and bad "versions" of group info data
  floating around, and these two commands access different versions.
- Only goes wrong for nntp groups
- Once you hit "s", everything is fine (and the dribble file is
  deleted).
- The code appears to be confused not about which articles are read, but
  how many/which articles exist in the group. 


Both "g" and "M-g" will eventually arrive at
`gnus-get-unread-articles-in-group', and in the "g" case the info and
active numbers are already wrong at that point. My current best guess is
that, in the "M-g" case, the code will issue a 'request-scan call first,
which updates the "real" active numbers for the group. nntp has no
`nntp-request-scan' function (while nnimap, nnmaildir, etc, do), which
might explain why the bug only shows up for nntp.

So then the remaining mysteries are why does "s" clear it up, and what
in my code changes could have caused this? Since I was mostly messing
with the hash tables, I have to assume that data was supposed to be
stored in some table, but isn't being retrieved correctly.

Anyway, I'm just thinking out loud, I know what the next debugging steps
are. I found another minor dribble-related bug, and will push a fix for
that in a bit.

Eric