Skip to content

test(platform-update): surface git stderr so the intermittent exit-128 is diagnosable - #270

Closed
hamzamerzic wants to merge 2 commits into
mobius-os:mainfrom
hamzamerzic:fix/surface-git-stderr-platform-update
Closed

test(platform-update): surface git stderr so the intermittent exit-128 is diagnosable#270
hamzamerzic wants to merge 2 commits into
mobius-os:mainfrom
hamzamerzic:fix/surface-git-stderr-platform-update

Conversation

@hamzamerzic

Copy link
Copy Markdown
Collaborator

Problem

test_platform_update.py intermittently 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: _git runs with check=True, and CalledProcessError's message is only "Command … returned non-zero exit status N"git's own fatal: 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 --auto child 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 the CalledProcessError type. The next time this flakes in CI, the traceback will show git's actual fatal: 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

  • Full test_platform_update.py suite: 66 passed.
  • A real exit 128 (git commit outside a repo) now reports git stderr: fatal: not a git repository … via the note.

…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 hamzamerzic added area: infrastructure Build, CI, deployment, and recovery maintenance Internal cleanup, dependency, or upkeep work labels Jul 27, 2026
@hamzamerzic
hamzamerzic enabled auto-merge (squash) July 27, 2026 16:50
@hamzamerzic

Copy link
Copy Markdown
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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: infrastructure Build, CI, deployment, and recovery maintenance Internal cleanup, dependency, or upkeep work

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant