Re: [PATCH v2 2/3] fetch-pack: in protocol v2, in_vain only after ACK

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Jonathan,

On Mon, 27 Apr 2020, Jonathan Tan wrote:

> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index baa1a99f45..961cd6beec 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -385,6 +385,24 @@ test_expect_success 'clone shallow with packed refs' '
>  	test_cmp count8.expected count8.actual
>  '
>
> +test_expect_success 'in_vain not triggered before first ACK' '
> +	rm -rf myserver myclient trace &&
> +	git init myserver &&
> +	test_commit -C myserver foo &&
> +	git clone "file://$(pwd)/myserver" myclient &&
> +
> +	# MAX_IN_VAIN is 256. Because of batching, the client will send 496
> +	# (16+32+64+128+256) commits, not 256, before giving up. So create 496
> +	# irrelevant commits.
> +	test_commit_bulk -C myclient 496 &&
> +
> +	# The new commit that the client wants to fetch.
> +	test_commit -C myserver bar &&
> +
> +	GIT_TRACE_PACKET="$(pwd)/trace" git -C myclient fetch --progress origin &&
> +	test_i18ngrep "Total 3 " trace

This just failed in one of the Pipelines I monitor:
https://github.com/git-for-windows/git-sdk-64/runs/648253955?check_suite_focus=true

The short of it is:

-- snip --
[...]
packet:     sideband< \2Enumerating objects: 4, done.
packet:     sideband< \2Counting objects: 25% (1/4)\15Counting objects:  50% (2/4)\15Counting objects:  75% (3/4)\15Counting objects: 100% (4/4)\15Counting obj
packet:     sideband< \2ects: 100% (4/4), done.Compressing objects:  50% (1/2)\15Compressing objects: 100% (2/2)\15Compressing objects: 100% (2/2), done.T
packet:     sideband< \2otal 3 (delta 0), reused 0 (delta 0), pack-reused 0
packet:     sideband< PACK ...
packet:  upload-pack> 0000
packet:     sideband< 0000
++ return 1
error: last command exited with $?=1
t/t5500-fetch-pack.sh:388: error: not ok 43 - in_vain not triggered before first ACK
#
#		rm -rf myserver myclient trace &&
#		git init myserver &&
#		test_commit -C myserver foo &&
#		git clone "file://$(pwd)/myserver" myclient &&
#
#		# MAX_IN_VAIN is 256. Because of batching, the client will send 496
#		# (16+32+64+128+256) commits, not 256, before giving up. So create 496
#		# irrelevant commits.
#		test_commit_bulk -C myclient 496 &&
#
#		# The new commit that the client wants to fetch.
#		test_commit -C myserver bar &&
#
#		GIT_TRACE_PACKET="$(pwd)/trace" git -C myclient fetch --progress origin &&
#		test_i18ngrep "Total 3 " trace
-- snap --

In other words, that `test_i18ngrep` assumes incorrectly that "Total 3"
will be found in the trace, but the sideband is totally allowed to cut
through it and deliver it in different packets.

This makes t5500 flaky.

Ciao,
Johannes

> +'
> +
>  test_expect_success 'fetch in shallow repo unreachable shallow objects' '
>  	(
>  		git clone --bare --branch B --single-branch "file://$(pwd)/." no-reflog &&
> --
> 2.26.2.303.gf8c07b1a785-goog
>
>
>