On Tue, Apr 23, 2019 at 11:45:17AM +0900, Junio C Hamano wrote: > 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
