Re: [PATCH 6/6] remote-curl: ensure last packet is a flush

[Jeff King <peff@peff.net>]

On Fri, May 15, 2020 at 05:02:45PM -0400, Denton Liu wrote:

> On Wed, May 13, 2020 at 02:04:58PM -0400, Denton Liu wrote:
> > This is not a complete solution to the problem, however. It is possible
> > that a flush packet could be sent in the middle of a message and the
> > connection could die immediately after. Then, remote-curl would not
> > error out and fetch-pack would still be in the middle of a transaction
> > and they would enter deadlock. A complete solution would involve
> > reframing the stateless-connect protocol, possibly by introducing
> > another control packet ("0002"?) as a stateless request separator
> > packet which is always sent at the end of post_rpc().
> > 
> > Although this is not a complete solution, it is better than nothing and
> > it resolves the reported issue for now.
> 
> I managed to get the implementation of the control packet working. As a
> result, I will be dropping this patch in the next reroll and replacing
> it with the more complete solution. For anyone reviewing, feel free to
> skip this patch.

OK. I'm less concerned about a flush packet in the middle of the
response fooling us into thinking things are done, and more that there
may be responses which _don't_ end in a flush. But maybe they all do.

This (and the previous patch) are definitely adding an extra layer of
assumptions about what the protocol going over the rpc channel looks
like. That seems like it will introduce more fragility.

I do kind of like the idea of a stateless separator packet, if I
understand your meaning correctly. I'll wait to see what the patches
look like. :)

-Peff