Re: do people find t5504.8 flaky?

From: Jeff King <peff@peff.net>
Date: Apr 23, 2019, 03:02 UTC
Message-ID: <20190423030254.GA19604@sigill.intra.peff.net>
In-Reply-To: <xmqqmukh5tj6.fsf@gitster-ct.c.googlers.com>

On Tue, Apr 23, 2019 at 11:45:17AM +0900, Junio C Hamano wrote:

Show 8 quoted lines

> I have been seeing occasional failures of t5504-fetch-receive-strict
> test on the cc/replace-graft-peel-tags topic, but it seems that the
> fork point of that topic from the mainline already fails the same
> step #8, only less frequently.
> 
> The push is rejected as expected, but the remote side that receives
> the "push" fails and the local side does not leave an expected
> output we expect when the test fails.

No, I haven't seen it fail, nor does running with --stress turn up anything. But looking at the test I would not be at all surprised if we have races around error hangups. I believe that index-pack will die unceremoniously as soon as something fails to pass its fsck check.

The client will keep sending data, and may hit a SIGPIPE (or the network equivalent), depending on how much slack there is in the buffers, whether we hit the problem as a base object or after we receive everything and start resolving deltas, etc.

I think after seeing a fatal error we probably ought to consider pumping the rest of the bytes from the client to /dev/null. That's wasteful, but it's the only clean way to get a message back, I think. It would also give us the opportunity to complain about other objects, too, if there are multiple (it might make sense to abort before resolving deltas, though; at that point we have all of the data and that phase is very CPU intensive).

-Peff