Re: [PATCH v2] fetch-pack: try harder to read an ERR packet

[Jeff King <peff@peff.net>]

On Tue, Apr 28, 2020 at 01:59:57PM -0600, Taylor Blau wrote:

> > > When the server has hung up after sending an ERR packet to the
> > > client, the client might still be writing, for example a "done"
> > > line. Therefore the client might get a write error before reading
> > > the ERR packet.
> > >
> > > When fetching, this could result in the client displaying a
> > > "Broken pipe" error, instead of the more useful error sent by
> > > the server in the ERR packet.
> >
> > Hmm, if the connection gets severed just before the ERR packet the
> > other side has written, we will see "Broken pipe" if we write
> > "done", and no amount of "try to read to collect as much what they
> > said as possible" would help.  If you are lucky and the connection
> > is broken after the ERR reaches on this side, such an "extra effort"
> > may help, but is it really worth the effort?  It is not clear to me
> > if the extra complexity, one more API function people need to learn,
> > and the need to think which one to use every time they want to say
> > write_in_full(), are justifiable.
> >
> > I dunno.
> 
> I think that you're right. The more that I thought about my suggestion,
> the more dumb I was convinced that it was.

Now I'm confused about which suggestion. The overall patch's purpose is
still good, I think (see my other response). But I agree that having an
alternate write_in_full() is spreading the hack too far outside of
fetch-pack (and as I wrote in [1], I really don't understand what it's
trying to do).

-Peff

[1] https://lore.kernel.org/git/20200428083336.GA2405176@coredump.intra.peff.net/