Windows builds hang when the HEAD commit message is large (Invoke-Git deadlock)
Ninguém assumiu esta issue ainda.
- Linguagem predominante
- PowerShell
- Estrelas
- 145
- Forks
- 27
- Merge médio
- 10h 16min
- PRs com merge (30d)
- 34
Descrição
Part of #120. Found while verifying the #162 merge.
Symptom
On Windows, Set-BuildEnvironment hangs forever when the HEAD commit message is large. Nothing
is printed, no error, no timeout — the build never starts.
This is currently happening on main. The push-triggered CI run for 9720cb7 hung both Windows
legs for 27+ minutes with zero output (ubuntu and macOS passed); I cancelled it. Every local
./build.ps1 on Windows hangs the same way, because build.ps1 calls Set-BuildEnvironment -Force before Invoke-psake.
Root cause
BuildHelpers\Invoke-Git (2.0.16) 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 someone to drain the
pipe, and Invoke-Git blocks waiting for git to exit. Neither can proceed. It is the textbook
WaitForExit-before-ReadToEnd deadlock described in the
ProcessStartInfo.RedirectStandardOutput remarks.
Get-BuildVariable calls it as Invoke-Git log --format=%B -n 1 <sha> to populate
$env:BHCommitMessage, so the payload is the full commit message body.
Reproduction
Measured on Windows 11, PowerShell 7.6.4, BuildHelpers 2.0.16, against real commits on main:
| Commit | Message size | Result |
|---|---|---|
f726f48 |
2617 bytes | returns |
64b7207 |
5498 bytes | returns |
9720cb7 |
5757 bytes | hangs |
Import-Module BuildHelpers
Invoke-Git -Arguments 'log --format=%B -n 1 9720cb7' # never returns on Windows
Linux and macOS have a larger pipe buffer and do not hit the threshold at these sizes, which is
why only the Windows legs hang.
Why CI did not catch it before merge
On a pull_request event, GitHub checks out a synthetic merge commit whose message is short
(Merge <sha> into <sha>). The real squash message only becomes HEAD on the push to main.
Every PR will be green and then hang main if its squashed body is large enough.
This repository writes long PR bodies and squash-merges them verbatim, so the trigger is not
exotic — it is the house style. #163 and #165 both have bodies over the threshold today.
Consumer impact
This is not only a repo-internal problem. Initialize-PSBuild calls Set-BuildEnvironment, so
any consumer building on Windows hangs when their own HEAD commit message crosses the threshold.
A hang with no output is a bad failure mode to ship at 1.0.0.
Options
- Stop passing the payload through
Invoke-Git. Populate$env:BHCommitMessageourselves
before callingSet-BuildEnvironment, or truncate it. Narrow, immediate, ours to control - Fix upstream. Read the streams asynchronously (
BeginOutputReadLine, orReadToEnd
beforeWaitForExit) and PR it to BuildHelpers, then raise theRequiredModulesfloor once
released. Correct fix, slowest path - Trim squash commit messages at merge time. Pure process change, no code — but it depends
on every future merge remembering, and it does nothing for consumers - Drop the BuildHelpers dependency for this variable. Largest change; worth naming only
because #120 already asks what 1.0.0 should depend on
Options 1 and 2 are not exclusive: 1 unblocks now, 2 fixes it for everyone.
Immediate mitigation
Until this is fixed, squash-merge with a short commit body on this repo. The full PR
description stays on the pull request either way.
Done when
./build.ps1 and Windows CI complete regardless of HEAD commit message size, with a regression
test covering a message larger than the pipe buffer.
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Direção de pesquisa
Comece com build.ps1 e o caminho de Set-BuildEnvironment; depois inspecione BuildHelpers\Invoke-Git e Get-BuildVariable para confirmar como a mensagem do commit é lida. Reproduza o travamento com Invoke-Git log --format=%B -n 1 9720cb7 no Windows e revise #120 antes de escolher entre as opções de mitigação listadas. Considera-se concluído quando ./build.ps1 e o Windows CI forem concluídos para mensagens grandes de HEAD, com um teste de regressão cobrindo uma mensagem maior que o buffer do pipe.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Stack de tecnologia
- git, powershell
- Domínio
- build-system, ci-cd, tooling
- Tipo de issue
- Bug
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Status de atividade
- Ativa
- Clareza
- Razoavelmente clara
- Facilidade para iniciantes
- 50/100