Hangs on long commit message

[JustinGrote]

I did a squash merge of a branch with ~100 commits in it, leading to a very long commit message. Set-Build environment hangs at that point. When I did a git commit --amend to shorten it, Set-BuildEnvironment started working fine again.

Not sure if its a poshGit downstream issue or what, just FYI.

[tablackburn]

Hitting this on PowerShell 7.4 / Windows 11 / BuildHelpers 2.0.16 with a deterministic reproducer.

Repro (same repo, same machine, fresh pwsh session each time):

HEAD commit body size	Result
1585 bytes	Set-BuildEnvironment -Force returns in <1s, build completes in ~10s
5249 bytes	hangs indefinitely (killed at 10+ min, 0% CPU, no I/O, no file locks)
759 bytes (amended from the 5249-byte commit)	builds fine again

Reproduces for two different developers on the same project. Not session state.

Hang location: between Invoke-psake being called and any psake task body running — no task output ever appears, just the prior Invoke-PSDepend warnings on stderr.

Likely mechanism (sharing in case it helps whoever picks this up): Get-BuildVariable builds its git log command by string-interpolating the value of a matched CI env var into the argument list:

Invoke-Git ... "log --format=%B -n 1 $((Get-Item -Path "ENV:$_").Value)"

If a CI variable like BUILD_SOURCEVERSIONMESSAGE is already populated with the multi-KB commit body itself, that body gets substituted as a git argument, producing a malformed/huge command line and (apparently) stalling the Invoke-Git pipe drain. This dovetails with #109, where the same switch is called out for non-deterministic matching across CI branches.

Speculative fix that would close both this and #109: add break after each switch case, and use only the env-var name (or its path, where applicable) as the -C argument to git — never its value.

Windows 32,767-char env block limit (docs) isn't the cause: 5,249 bytes is well under it, and PowerShell/PowerShell#14110 (the analogous hard-error case) was fixed in 7.1.3.

Happy to test a patch against the 5249-byte repro if anyone takes a swing at this.

[tablackburn]

Following up on my own comment above: I found the mechanism, and my earlier guess about the switch and env-var interpolation was wrong. Nothing about how the git command is built matters. Invoke-Git deadlocks on any output larger than the pipe buffer, and the commit message is simply the easiest way to exceed it.

Root cause

Public/Invoke-Git.ps1 (2.0.16), lines 103-112:

$null = $p.Start()
$p.WaitForExit()                               # blocks until git exits
...
if($stdout = $p.StandardOutput.ReadToEnd())    # pipe drained only afterwards

Both streams are redirected, so git writes into an OS pipe with a fixed-size buffer. Once that buffer fills, git blocks on write and cannot exit. WaitForExit() is already blocking, waiting for the exit that can now never happen. Classic redirected-child deadlock — it is the exact case the .NET docs for ProcessStartInfo.RedirectStandardOutput warn about.

The threshold is the pipe buffer, exactly

Bisected on Windows 11 (10.0.26200) / PowerShell 7.6.5 / git 2.55.0.windows.3 / BuildHelpers 2.0.16, one commit per run in a throwaway repo, calling git log --format=%B -n 1 through the same Start -> WaitForExit -> ReadToEnd ordering:

commit message	git stdout	result
4,093 bytes	4,095	completes
4,094 bytes	4,096	completes
4,095 bytes	4,097	deadlock
4,096 bytes	4,098	deadlock

4,096 bytes of stdout is the last size that works. That is the Windows anonymous pipe buffer, and it is why this looks size-dependent and arbitrary: my earlier 1,585-vs-5,249 datapoints just happened to straddle it.

This also explains why it never reproduces on Linux or macOS CI, where the pipe buffer is 64 KiB — a commit message would have to be sixteen times longer.

Reproducer without BuildHelpers

This is process handling, not anything in Get-BuildVariable, so it reproduces with no BuildHelpers involved:

$repo = Join-Path ([IO.Path]::GetTempPath()) 'pipe-repro'
New-Item -ItemType Directory -Path $repo -Force | Out-Null
Push-Location $repo
git init --quiet
git config user.email 'a@b.invalid'; git config user.name 'repro'
git commit --quiet --allow-empty -m ('x' * 4095)

$pinfo = [Diagnostics.ProcessStartInfo]::new()
$pinfo.FileName = 'git'; $pinfo.Arguments = 'log --format=%B -n 1'
$pinfo.WorkingDirectory = $repo; $pinfo.UseShellExecute = $false
$pinfo.RedirectStandardOutput = $true; $pinfo.RedirectStandardError = $true

$p = [Diagnostics.Process]::new(); $p.StartInfo = $pinfo
$null = $p.Start()
$p.WaitForExit(5000)   # $false - git is still alive, blocked writing

Drop the message to 4,094 bytes and it returns $true.

Fix

Drain the streams before waiting. Verified on a 200,000-byte commit message, same repo, same redirects, only the ordering changed:

current  (WaitForExit -> ReadToEnd) : exited=False  stdout=n/a
proposed (async drain -> WaitForExit): exited=True   stdout=200002

$null = $p.Start()
$stdoutTask = $p.StandardOutput.ReadToEndAsync()
$stderrTask = $p.StandardError.ReadToEndAsync()
$p.WaitForExit()
$stdout = $stdoutTask.GetAwaiter().GetResult()
$stderr = $stderrTask.GetAwaiter().GetResult()

Reading both asynchronously matters: draining stdout synchronously before WaitForExit still deadlocks if it is stderr that fills first.

Scope is wider than commit messages

Any Invoke-Git call whose output exceeds 4 KiB on Windows hangs the same way — Invoke-Git log, Invoke-Git diff, Invoke-Git status in a large working tree. Get-BuildVariable is just the most common path there, because git log --format=%B -n 1 puts an arbitrary, user-controlled string on stdout. -Raw and -Quiet do not help; they change what is returned after the read, not the order of the read.

Practical note for anyone hitting this in CI: the failure mode is a job that produces no output at all and burns its timeout, with no error to search for. A squash merge of a long PR description is enough to trigger it, and reverting the code change will not fix it, because the commit message is the input.

Happy to open a PR with the reordering plus a regression test if that is welcome.

[tablackburn]

Root cause, if it is useful to whoever picks this up — the symptom here is exactly reproducible and it is not poshGit.

Invoke-Git redirects both output streams and then waits for the process to exit before reading them:

$pinfo.RedirectStandardError  = $RedirectStandardError   # $true
$pinfo.RedirectStandardOutput = $RedirectStandardOutput  # $true
...
$null = $p.Start()
$p.WaitForExit()                        # <-- blocks here
...
$stdout = $p.StandardOutput.ReadToEnd() # <-- never reached

When git writes more than the pipe buffer holds, git blocks waiting for the pipe to be drained and Invoke-Git blocks waiting for git to exit. Neither can proceed. This is the deadlock described in the ProcessStartInfo.RedirectStandardOutput remarks:

A deadlock condition can result if the parent process calls p.WaitForExit before p.StandardOutput.ReadToEnd and the child process writes enough text to fill the redirected stream.

Get-BuildVariable calls Invoke-Git log --format=%B -n 1 <sha>, so the payload is the full commit message body — which is why a squash merge triggers it and git commit --amend to shorten fixes it.

Measured threshold

Windows 11, PowerShell 7.6.4, BuildHelpers 2.0.16, against real commits:

Message size	Result
2617 bytes	returns
5498 bytes	returns
5757 bytes	hangs

Minimal repro:

Import-Module BuildHelpers
Invoke-Git -Arguments "log --format=%B -n 1 <sha-with-a-large-message>"

Linux and macOS have a larger default pipe buffer and do not reach the threshold at these sizes, so it presents as Windows-only.

Fix

Read the streams before waiting, or read them asynchronously — ReadToEnd before WaitForExit, or BeginOutputReadLine/BeginErrorReadLine with WaitForExit. Note that reading stdout to the end and then stderr can deadlock on the other stream, so both need draining concurrently if both are redirected.

Why this is worth more than it looks

Any project that squash-merges with a full PR body in the commit message will hit this, and the failure mode is a hang with no output rather than an error. In CI it is worse: on a pull_request event GitHub checks out a synthetic merge commit with a short message (Merge <sha> into <sha>), so the build is green — the real message only becomes HEAD on the push to the default branch. Every pull request goes green and then hangs the default branch.

We hit this in psake/PowerShellBuild#167, where Initialize-PSBuild calls Set-BuildEnvironment; that issue has the full write-up. Happy to open a PR here if that would help, but I understand adoption of this module by the PowerShell org was approved recently (powershellorg/.github#14), so I did not want to send one unsolicited mid-transfer.