fix(test): de git-testhulp hing op dezelfde pijp als de app deed #968

Merged

brenno merged 1 commit from fix/rawgit-pijp into main

2026-07-29 19:03:52 +00:00

brenno commented

2026-07-29 19:03:47 +00:00

Owner

Vervolg op #966. Die PR repareerde de onbegrensde wacht op de uitvoer-pijp in
NativeGitCli._spawn. De ijkdraai op de oude main (GitHub-run 30477369421)
liet daarna zien dat er een tweede plek met precies dezelfde fout zit — en
waarschijnlijk de plek waar het werkelijk misging.

Wat de ijkdraai liet zien

❌ native_git_mirror_test.dart: native commit/push commitDeck landt op de
   forge, met de pool-blob (failed)
TimeoutException after 0:03:00.000000
Bad state: git commit -m init → fatal: not a git repository

Opnieuw een ánder testgeval dan alle vorige draaien, opnieuw drie minuten stil,
opnieuw geen stack — en Linux en macOS groen.

De tweede pijp

_rawGit, de hulp die elk geval in dit bestand opbouwt, draaide git via
Process.run. Die wacht net zo onbegrensd tot de pijp sluit als _spawn deed.
Nagemeten met hetzelfde proefje als in #966:

Process.run kwam terug na 10022 ms, exit=0, stdout=hallo

Het kind was na een paar milliseconden klaar; de tien seconden zijn de
levensduur van het kleinkind.

Dat maakt dit de waarschijnlijkere van de twee vastlooplocaties: vrijwel elke
setUp in dit bestand doet clone en push langs deze hulp, en dát zijn de
commando's die git-upload-pack/git-receive-pack als kleinkind starten. Het
verklaart wat aan #966 alleen niet goed te verklaren was — waarom het elke
draai een ander geval trof, en waarom de time-out geen stack opleverde.

De wijziging

_rawGit loopt nu langs debugSpawn, zodat de testhulp de gerepareerde vorm
erft in plaats van er een tweede, zwakkere kopie van te zijn. Twee dingen
die daarbij horen:

Het milieu gaat expliciet mee. debugSpawn sluit het
(includeParentEnvironment: false, de kern van §10.2), en zonder
SystemRoot/PATHEXT start CreateProcess op Windows niet — dezelfde reden als
bij _smokeEnv in git_cli_test (#926). GIT_CONFIG_GLOBAL wordt op
Windows NUL in plaats van /dev/null.
Een tijdslimiet van 120 s als tweede vangnet, voor een git die zélf niet meer
terugkomt. Ruim, want dit draait ook op een zwaarbelaste CI-machine, en een
limiet die afloopt hoort iets te betekenen.

Waarom hier geen aparte regressietest bij zit

De regressie die dit bewaakt zit in _spawn, en díe is in #966 al vastgelegd
met een geval dat rood staat zonder de fix (10 s versus 2 s). Deze PR verwijdert
alleen de weg eromheen. Een tweede test die hetzelfde nogmaals aantoont zou
niets bewaken wat nu niet al bewaakt is; wat hier gecontroleerd hoort te worden
is dat de suite die weg niet opnieuw inslaat, en dat is de import van
Process.run die er niet meer staat.

Poorten

make check — groen (exit 0).
flutter test test/native_git_mirror_test.dart — 30 gevallen groen in 4 s.
Bewaker bewust niet gehaald: dit raakt geen bestandsformaat, opslag,
afhankelijkheid, uitgaand verkeer of publieke belofte. Het is een testhulp.

Voorbehoud

De Windows-leg is niet lokaal te toetsen. Of dit de vastloper wegneemt, blijkt
pas uit een workflow_dispatch-draai op de spiegel ná de merge — de flakiness
was intermitterend, dus één groene draai is een aanwijzing en geen bewijs.

Vervolg op #966. Die PR repareerde de onbegrensde wacht op de uitvoer-pijp in `NativeGitCli._spawn`. De ijkdraai op de oude main (GitHub-run 30477369421) liet daarna zien dat er een **tweede** plek met precies dezelfde fout zit — en waarschijnlijk de plek waar het werkelijk misging. ## Wat de ijkdraai liet zien ``` ❌ native_git_mirror_test.dart: native commit/push commitDeck landt op de forge, met de pool-blob (failed) TimeoutException after 0:03:00.000000 Bad state: git commit -m init → fatal: not a git repository ``` Opnieuw een ánder testgeval dan alle vorige draaien, opnieuw drie minuten stil, opnieuw geen stack — en Linux en macOS groen. ## De tweede pijp `_rawGit`, de hulp die elk geval in dit bestand opbouwt, draaide git via `Process.run`. Die wacht net zo onbegrensd tot de pijp sluit als `_spawn` deed. Nagemeten met hetzelfde proefje als in #966: ``` Process.run kwam terug na 10022 ms, exit=0, stdout=hallo ``` Het kind was na een paar milliseconden klaar; de tien seconden zijn de levensduur van het kleinkind. Dat maakt dit de waarschijnlijkere van de twee vastlooplocaties: vrijwel elke `setUp` in dit bestand doet `clone` en `push` langs deze hulp, en dát zijn de commando's die `git-upload-pack`/`git-receive-pack` als kleinkind starten. Het verklaart wat aan #966 alleen niet goed te verklaren was — waarom het elke draai een *ander* geval trof, en waarom de time-out geen stack opleverde. ## De wijziging `_rawGit` loopt nu langs `debugSpawn`, zodat de testhulp de gerepareerde vorm **erft** in plaats van er een tweede, zwakkere kopie van te zijn. Twee dingen die daarbij horen: * Het milieu gaat expliciet mee. `debugSpawn` sluit het (`includeParentEnvironment: false`, de kern van §10.2), en zonder SystemRoot/PATHEXT start `CreateProcess` op Windows niet — dezelfde reden als bij `_smokeEnv` in `git_cli_test` (#926). `GIT_CONFIG_GLOBAL` wordt op Windows `NUL` in plaats van `/dev/null`. * Een tijdslimiet van 120 s als tweede vangnet, voor een git die zélf niet meer terugkomt. Ruim, want dit draait ook op een zwaarbelaste CI-machine, en een limiet die afloopt hoort iets te betekenen. ## Waarom hier geen aparte regressietest bij zit De regressie die dit bewaakt zit in `_spawn`, en díe is in #966 al vastgelegd met een geval dat rood staat zonder de fix (10 s versus 2 s). Deze PR verwijdert alleen de weg eromheen. Een tweede test die hetzelfde nogmaals aantoont zou niets bewaken wat nu niet al bewaakt is; wat hier gecontroleerd hoort te worden is dat de suite die weg niet opnieuw inslaat, en dat is de import van `Process.run` die er niet meer staat. ## Poorten * `make check` — groen (exit 0). * `flutter test test/native_git_mirror_test.dart` — 30 gevallen groen in 4 s. * Bewaker bewust niet gehaald: dit raakt geen bestandsformaat, opslag, afhankelijkheid, uitgaand verkeer of publieke belofte. Het is een testhulp. ## Voorbehoud De Windows-leg is niet lokaal te toetsen. Of dit de vastloper wegneemt, blijkt pas uit een `workflow_dispatch`-draai op de spiegel ná de merge — de flakiness was intermitterend, dus één groene draai is een aanwijzing en geen bewijs.

brenno added 1 commit

2026-07-29 19:03:47 +00:00

fix(test): de git-testhulp hing op dezelfde pijp als de app deed

scans / scans (pull_request) Successful in 3m18s

Details

da1730260a

`_rawGit` — de hulp die elk geval in native_git_mirror_test opbouwt — draaide
git via `Process.run`, en die wacht net zo onbegrensd tot de uitvoer-pijp
sluit als `_spawn` deed vóór 6f15d62f. Nagemeten: een kind dat na 4 ms klaar
is maar een kleinkind achterlaat, laat `Process.run` 10.022 ms wachten.

Dat maakt dit de waarschijnlijkere vastlooplocatie van de twee. Vrijwel elke
setUp in dat bestand doet `clone` en `push` langs deze hulp, en dát zijn de
commando's die `git-upload-pack`/`git-receive-pack` als kleinkind starten —
wat verklaart waarom de Windows-leg elke draai op een ánder testgeval strandde
en waarom de time-out van drie minuten geen stack opleverde.

De hulp loopt nu langs `debugSpawn`, zodat ze de gerepareerde vorm erft in
plaats van er een tweede, zwakkere kopie van te zijn. Het milieu gaat
expliciet mee, want `debugSpawn` sluit het (§10.2) en zonder SystemRoot/PATHEXT
start `CreateProcess` op Windows niet — dezelfde reden als bij `_smokeEnv` in
git_cli_test (#926). De tijdslimiet van 120 s is het tweede vangnet, voor een
git die zélf niet meer terugkomt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

brenno merged commit 84702f39b7 into main

2026-07-29 19:03:52 +00:00

brenno referenced this pull request from a commit

2026-07-29 19:03:53 +00:00

Merge pull request 'fix(test): de git-testhulp hing op dezelfde pijp als de app deed' (#968) from fix/rawgit-pijp into main

brenno referenced this pull request from a commit

2026-07-29 20:17:41 +00:00

test(windows): ruimere marges voor de git-suite, als aanvaarde afweging

brenno referenced this pull request

2026-07-29 20:18:08 +00:00

test(windows): ruimere marges voor de git-suite, als aanvaarde afweging #970