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

Since 00fa8502354 (ci: bump debian-11 job to debian-12, 2026-09-05), the `debian-12` job has intermittently failed t5559's half-auth clone with:

  curl 92 Stream error in the HTTP/2 framing layer

Anonymous discovery succeeds, but the upload-pack POST requires authentication. Apache can return an early 401 and close the HTTP/2 stream before libcurl finishes sending the request body. Debian 12's curl 7.88.1 treats that closure as a transport error instead of allowing an authentication retry. Curl fixed this handling in 331b89a319d0 (http2: polish things around POST), included in 8.3.0: https://github.com/curl/curl/pull/11756

This did not happen before switching to Debian 12 because Debian 11 ships with libcurl 7.74.0-1.3+deb11u16, which does not have that bug.

Replacing the packaged libcurl with a modern build would defeat this job's purpose of testing older supported distributions. So let's simply exclude the flaky t5559.15 and its dependent t5559.16 on Debian 12 until the packaged curl carries the fix (or until the end of time, whichever comes first).

Assisted-by: GPT-6 Astra
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
    ci: work around Debian 12's HTTP/2 authentication failures
    
    While this is a regression in v2.56, it does not affect production code,
    it's just working around a flaky test. In other words: This patch does
    not need to be fast-tracked into v2.56.0, but it would be good to get it
    into master pretty soon after that, to reduce developer friction.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2236%2Fdscho%2Fwork-around-debian-curl-stream-error-92-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2236/dscho/work-around-debian-curl-stream-error-92-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2236

 ci/lib.sh | 6 ++++++
 1 file changed, 6 insertions(+)

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Superb.  A well written diagnosis like this is worth a ton.

Oh, 100% agree with the reasoning.  Thanks for this workaround.

Yes. I do not think there is any reason to cook it as long as other usual patches. Fast-tracking would make sure other things do keep working on older Debian.

Thanks.

On Tue, Sep 22, 2026 at 11:06:13PM +0000, Johannes Schindelin via GitGitGadget wrote:

Thanks for finding and fixing. I saw this yesterday but hadn't had time to dig in yet, and your explanation is very satisfying. :)

That should reduce the immediate CI pain, though I can think of two downsides:

  - we're detecting based on CI job name, not on the presence of the
    known bug. So it won't help anybody running the tests themselves
    (even people on debian-12!)

  - we're relying on test numbering, which can change over time. So if
    we add new setup tests early in t5559 (actually, t5551 which it's
    based on!) these will silently go out of sync.

So an ideal solution to me would be more like t5559 checking for the buggy version itself, setting a prereq, and then marking the tests with !HAVE_CURL_HTTP2_BUG.

That said, I'm not sure how tricky that would be to implement. We give the curl version with "git version --build-options", but we'd have to do some version number comparisons. It might not be worth spending a lot of time on this.

-Peff

On Wed, Sep 23, 2026 at 12:47:01PM -0400, Jeff King wrote:

I guess our robot overlords^Whelpers could help with that. I passed your patch and my email to Astra, which came up with this:

On Wed, Sep 23, 2026 at 12:53:48PM -0400, Jeff King wrote:

OK, last email, I promise, since you could probably be feeding this to Astra just as easily as I am (and you did the actual interesting work on the patch of figuring out the problem, so I'll leave it to you decide which approach you like). The range version is something like this:

Jeff King <peff@peff.net> writes:

Just nitpicking the wording, but if the first affected version is truly unknown, assuming that versions from 7.88.1 up is *not* a conservative thing to do at all, is it?

If 7.88.1 is from an irrelevantly ancient past, I would say that we should just skip anything older than 8.3.0, but 7.88.1 is from early 2023 and we cannot do such a simplification.

On Wed, Sep 23, 2026 at 10:17:05AM -0700, Junio C Hamano wrote:

It depends on what bad outcome we are being conservative against. If the bad outcome is skipping the test on a version for which we could reliably use it, then it is conservative to only select known-bad versions. If the bad outcome is somebody running the test and seeing a flaky fail, then yes, the more conservative thing would be extending to skip older unknown versions (potentially up to "forever").

I think you could argue either way (and I am OK with either, or even just matching 7.88.1).

-Peff

Hi Jeff,

On Wed, 23 Sep 2026, Jeff King wrote:

I had GPT-6 dig deeper into the issue, since you're right: This should not be a CI/Debian-only gate, at the same time I didn't know what was the first version with the bug, so I suspected the version range to be subtly inaccurate. Turns out that the bug appeared first in cURL v7.88.0. So I adjusted your version range in preparation for the next patch iteration.

Thank you! Johannes

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Great digging.  So it is between 7.88.0 and 8.3.0?

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

Since 00fa8502354 (ci: bump debian-11 job to debian-12, 2026-09-05), the `debian-12` job has intermittently failed t5559's half-auth clone with:

  curl 92 Stream error in the HTTP/2 framing layer

Anonymous discovery succeeds, but the upload-pack POST requires authentication. Apache can return an early 401 and close the HTTP/2 stream before libcurl finishes sending the request body. Debian 12's curl 7.88.1 treats that closure as a transport error instead of allowing an authentication retry. Curl fixed this handling in 331b89a319d0 (http2: polish things around POST), included in 8.3.0: https://github.com/curl/curl/pull/11756

This did not happen before switching to Debian 12 because Debian 11 ships with libcurl 7.74.0-1.3+deb11u16, which does not have that bug, it was only introduced in cURL 7.88.0.

Replacing the packaged libcurl with a modern build would defeat this job's purpose of testing older supported distributions. So let's simply skip the flaky test cases when a buggy libcurl version is detected.

Assisted-by: GPT-6 Astra, GPT-6 Sol
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
    ci: work around Debian 12's HTTP/2 authentication failures
    
    While this is a regression in v2.56, it does not affect production code,
    it's just working around a flaky test. In other words: This patch does
    not need to be fast-tracked into v2.56.0, but it would be good to get it
    into master pretty soon after that, to reduce developer friction.
    
    Changes since v1:
    
     * Instead of hard-coding the test case numbers specifically on Debian
       12, thanks to Jeff King the test cases now have a
       libcurl-version-gating prereq.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2236%2Fdscho%2Fwork-around-debian-curl-stream-error-92-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2236/dscho/work-around-debian-curl-stream-error-92-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2236

Range-diff vs v1:

 1:  1dfabf3ece < -:  ---------- ci: work around Debian 12's HTTP/2 authentication failures
 -:  ---------- > 1:  e4c5658fb1 ci: work around Debian 12's HTTP/2 authentication failures

 t/t5551-http-fetch-smart.sh | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

On Thu, Sep 24, 2026 at 08:59:24PM +0200, Johannes Schindelin wrote:

Great, it feels nicer knowing the actual start point. Your v2 patch looks good to me!

-Peff

On Thu, Sep 24, 2026 at 08:53:49PM +0000, Johannes Schindelin via GitGitGadget wrote:

Doh, this is totally broken. The prereq snippet is in double-quotes, so the $1, etc in the awk invocation are interpolated before we even eval it. Fix is below.

-- >8 --
Subject: [PATCH] t5551: fix quoting in curl version bug prereq

We have a prereq snippet that invokes awk. The awk script's $1, etc, variables need to be quoted to avoid shell interpolation. We correctly use a single-quote inside the prereq snippet, but the snippet itself is contained in double-quotes. So we interpolate "$1" into whatever value that happens to have in the outer shell, and eval nonsense like:

  awk '(--some-garbage == 7 && --other-garbage >= 88) ...'

As a result, we don't think we have a buggy curl version even when we do, and run the test anyway. But of course it's easy not to notice, since this prereq was protecting us from a racy bug. It only breaks sometimes.

There are a few options for fixing the quoting:

  1. Backslash-escaping the dollar signs. This is perhaps the least-ugly
     version, but it's a minor hassle to remember if somebody touches
     the code later.

  2. Single-quote the snippet, then quote interior single-quotes as
     '\''. Reasonably obvious, but ugly.

  3. Use the '<<\EOT' here-doc trick to specify the snippet. This would
     look nice, but we don't yet support it for prereqs. ;)

This patch uses (2), and we can circle back to (3) to make it look nicer later.

Signed-off-by: Jeff King <peff@peff.net>
---
This should go on top of js/ci-debian-12-http2-workaround.

Since I know we both used GPT to work on this, I was curious if this slipped past it. Doesn't look like it from what I sent (which used option 2 above). I wonder if your agent flipped it, or if you saw how ugly it was and flipped it yourself. Not blaming, but it's just a funny and interesting data point if a human second-guessing the AI output introduced a bug.

 t/t5551-http-fetch-smart.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

On Mon, Oct 05, 2026 at 11:43:32PM -0400, Jeff King wrote:

Doing (3) turned out easier than I thought it would. Patch is below. I think it still makes sense to do the immediate fix with (2), and then this on top as cleanup (or as a separate topic, though obviously there is a textual dependency).

-- >8 --
Subject: test-lib: allow lazy prerequisite snippets as here-docs

Commit 1d133ae91f (test-lib: allow test snippets as here-docs, 2024-07-10) let test_expect_success and test_expect_failure read their snippets from stdin, making it easier to use single quotes within them. I mentioned there that we could extend this to lazy prerequisites, but left it for later.

Let's finish that off now. Since test_body_or_stdin() takes the name of the variable to fill, we can use it directly to populate the saved prereq snippet. We read the body when the prereq is declared, but still evaluate it only when the prereq is used.

Converting the curl version check in t5551 shows how this can reduce awkward quoting.

Signed-off-by: Jeff King <peff@peff.net>
---
 t/t5551-http-fetch-smart.sh | 8 ++++----
 t/test-lib-functions.sh     | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)