test(platform-update): surface git stderr so the intermittent exit-128 is diagnosable - #270
Closed
hamzamerzic wants to merge 2 commits into
Closed
Conversation
…gnosable This suite intermittently fails in CI with a git exit 128, but the cause was never visible: _git ran with check=True, whose CalledProcessError message is only 'Command ... returned non-zero exit status N' — git's own fatal line was swallowed. (An earlier guess that auto-gc caused it was wrong: at this commit count git's auto-gc does no work — 0 packs, no commit-graph/packed-refs — so it takes no lock and cannot race; the flake was not reproducible locally across ~13k commits incl. 16-way parallel.) Surface git's stderr as an exception note so the next occurrence names its own cause instead of leaving us to guess. Verified: full suite (66) green, and a real exit-128 now reports its 'fatal:' line. Co-authored-by: Möbius Agent <mobius-agent@users.noreply.github.com>
hamzamerzic
enabled auto-merge (squash)
July 27, 2026 16:50
5 tasks
Collaborator
Author
|
Merged to main as part of #304. Git stderr is now preserved in repository-helper failures and covered in the integrated change. |
auto-merge was automatically disabled
July 28, 2026 04:37
Pull request was closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
test_platform_update.pyintermittently fails in CI with a git exit 128 (it red-failed a recent batch and PR #246 before). But the cause has never been visible:_gitruns withcheck=True, andCalledProcessError's message is only "Command … returned non-zero exit status N" — git's ownfatal:line is swallowed, so CI logs never say what failed.What this is NOT
An earlier hypothesis blamed git auto-gc. That's wrong at this scale: the test's ~100-commit repo triggers no gc work (0 packs, no commit-graph/packed-refs, well under git's 6,700-object threshold), so the spawned
git gc --autochild is a no-op that takes no lock and can't race. The flake also did not reproduce locally across ~13k commits including 16-way parallel load — it's CI-environment-specific.Fix
Surface git's stderr. On a failing
_git, attach git's stderr as an exception note (err.add_note(...)), preserving theCalledProcessErrortype. The next time this flakes in CI, the traceback will show git's actualfatal:line — turning an undiagnosable flake into one we can fix at the root.This is deliberately a diagnosis change, not a blind "fix": the honest blocker to fixing the real cause is that the cause is invisible. This makes it visible.
Verification
test_platform_update.pysuite: 66 passed.exit 128(git commitoutside a repo) now reportsgit stderr: fatal: not a git repository …via the note.