bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[Eli Zaretskii <eliz@gnu.org>]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Fri, 29 Sep 2017 13:27:35 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, 28596@debbugs.gnu.org
> 
> At 10:13 -0400 on Tuesday 2017-09-26, N. Jackson wrote:
> >
> > The problem can be easily seen in the *Server* buffer. All my
> > nntp servers are broken.
> >
> > - The nntp servers that are managed by the Agent are in an
> >   "offline" state even though Gnus is currently plugged (and I
> >   have a good Internet connection), and the `O', `C' and `R'
> >   (open, close, and reset all) commands have not effect. (Toggling
> >   the plugged/unplugged state a few times hasn't changed this
> >   brokenness.)
> >
> > - The nntp servers that are not managed by the Agent are in a
> >   "denied" state and the `O', `C' and `R' (open, close, and reset
> >   all) commands have not effect.
> 
> It almost seems as if Gnus is in an "unplugged" state even though
> in the mode line it says that it's "plugged". (Toggling the
> plugged/unplugged state so that the mode line says it's
> "unplugged" doesn't help though.)
> 
> One reason why I think Gnus is actually "unplugged" is that when I
> enter a news group that is managed by the Agent when Gnus is
> "unplugged", the *Summary* buffer is displayed almost instantly.
> In contrast when Gnus is not in a "broken" state and is "plugged",
> loading the *Summary* buffer is slow as Gnus will retrieve headers
> over the Internet,
> 
> A second reason why I think Gnus is actually "unplugged" is that
> there are lines in news group *Summary* buffers like
> 
>   - .│0.0k│1969-12-31 19:00│ ▣ Gnus Agent               [Undownloaded article 218857]
> 
> which I would normally only see when Gnus is "unplugged".
> 
> I have now restarted Emacs to get Gnus back into a working state
> -- I have to get real work done. I will report more when I have
> time to investigate a "broken" instance of Gnus more thoroughly.

Any news on this?  Is this problem still present in the Emacs 26.0.90
pretest?