git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Jonathan Tan <jonathantanmy@google.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: [PATCH] t5500.43: make the check a bit more robust
Date: Tue, 13 Oct 2020 14:45:23 +0000	[thread overview]
Message-ID: <pull.753.git.1602600323973.gitgitgadget@gmail.com> (raw)

From: Johannes Schindelin <johannes.schindelin@gmx.de>

In 2b695ecd74d (t5500: count objects through stderr, not trace,
2020-05-06) we tried to ensure that the "Total 3" message could be
grepped in Git's output, even if it sometimes got chopped up into
multiple lines in the trace machinery.

However, the first instance where this mattered now goes through the
sideband machinery, where it is _still_ possible for messages to get
chopped up.

Note: we have code in `demultiplex_sideband()` _specifically_ to stitch
back together lines that were delivered in separate sideband packets.
However, this stitching fails when a primary packet is delivered in
between the two sideband packets: since a primary packet was received,
`demultiplex_sideband()` has to return that (and cannot wait for other
sideband packets, and therefore has to flush any incomplete line it
received).

This seems only to happen occasionally in the `vs-test` part of our CI
builds, i.e. with binaries built using Visual C, but not when building
with GCC or clang; The symptom is that t5500.43 fails to find a line
matching `remote: Total 3` in the `log` file, which ends in something
along these lines:

	remote: Tota
	remote: l 3 (delta 0), reused 0 (delta 0), pack-reused 0

To work around that, use some `sed` magic to re-stitch together those
split lines, after the fact.

The other test case touched by 2b695ecd74d (t5500: count objects through
stderr, not trace, 2020-05-06) is not affected by this issue because the
sideband machinery is not involved there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
    Work around flakiness in t5500.43
    
    It seems that this test became flaky only recently, although I have to
    admit that I have no idea why: the involved code does not seem to have
    changed recently at all. It should have been fixed by 
    https://lore.kernel.org/git/20200506220741.71021-1-jonathantanmy@google.com/
    , but apparently wasn't completely fixed, despite what I said in that
    thread.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-753%2Fdscho%2Funflake-t5500.43-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-753/dscho/unflake-t5500.43-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/753

 t/t5500-fetch-pack.sh | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 3557374312..5e556313af 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -400,7 +400,20 @@ test_expect_success 'in_vain not triggered before first ACK' '
 	test_commit -C myserver bar &&
 
 	git -C myclient fetch --progress origin 2>log &&
-	test_i18ngrep "remote: Total 3 " log
+	if ! test_i18ngrep "remote: Total 3 " log
+	then
+		# It is possible that the "Total 3" line is delivered in
+		# multiple sideband packets, and that a primary packet is
+		# delivered in between. When that happens, the line will be
+		# presented on multiple "remote:" lines.
+		sed "/^remote: T/{
+			:a
+			N
+			s/\nremote: //
+			ba
+		}" log >log.unsplit &&
+		test_i18ngrep "remote: Total 3 " log.unsplit
+	fi
 '
 
 test_expect_success 'in_vain resetted upon ACK' '

base-commit: d4a392452e292ff924e79ec8458611c0f679d6d4
-- 
gitgitgadget

             reply	other threads:[~2020-10-13 14:45 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 14:45 Johannes Schindelin via GitGitGadget [this message]
2020-10-13 17:53 ` [PATCH] t5500.43: make the check a bit more robust Junio C Hamano
2020-10-13 18:55 ` Jeff King
2020-10-13 19:07   ` Junio C Hamano
2020-10-13 19:09   ` Jeff King
2020-10-17  3:31     ` Johannes Schindelin
2020-10-17  2:34   ` Johannes Schindelin
2020-10-19 19:35 ` [PATCH v2 0/3] Work around flakiness in t5500.43 Johannes Schindelin via GitGitGadget
2020-10-19 19:35   ` [PATCH v2 1/3] sideband: avoid reporting incomplete sideband messages Johannes Schindelin via GitGitGadget
2020-10-20 20:33     ` Junio C Hamano
2020-10-20 20:48       ` Johannes Schindelin
2020-10-20 21:33         ` Junio C Hamano
2020-10-19 19:35   ` [PATCH v2 2/3] sideband: report unhandled incomplete sideband messages as bugs Johannes Schindelin via GitGitGadget
2020-10-19 19:35   ` [PATCH v2 3/3] sideband: add defense against packets missing a band designator Johannes Schindelin via GitGitGadget
2020-10-20 20:36     ` Junio C Hamano
2020-10-23  8:34     ` Jeff King
2020-10-23 14:44       ` Junio C Hamano
2020-10-23  8:48     ` Jeff King
2020-10-23  5:36       ` Johannes Schindelin
2020-10-23  8:50   ` [PATCH v2 0/3] Work around flakiness in t5500.43 Jeff King
2020-10-26 16:04     ` Johannes Schindelin
2020-10-26 16:09   ` [PATCH v3 0/2] " Johannes Schindelin via GitGitGadget
2020-10-26 16:09     ` [PATCH v3 1/2] sideband: avoid reporting incomplete sideband messages Johannes Schindelin via GitGitGadget
2020-10-26 16:09     ` [PATCH v3 2/2] sideband: report unhandled incomplete sideband messages as bugs Johannes Schindelin via GitGitGadget
2020-10-26 18:33     ` [PATCH v3 0/2] Work around flakiness in t5500.43 Junio C Hamano
2020-10-27  6:52     ` [PATCH] sideband: diagnose more incoming packet anomalies Jeff King
2020-10-27  7:12       ` Jeff King
2020-10-27 18:56         ` Junio C Hamano
2020-10-27 20:42           ` Jeff King
2020-10-27 21:38             ` Junio C Hamano
2020-10-28  9:33               ` Jeff King
2020-10-27  7:13       ` Jeff King
2020-10-27 19:04         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pull.753.git.1602600323973.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=jonathantanmy@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).