plan(v0.62): RQ-62-FEDAUTH — un-red main's R10, which caught my own commit exactly as designed - #1147
Merged
Merged
Conversation
…ommit exactly as designed Merging #1144 turned main red on R10: FAIL R10: delivery-shaped commit in the release window is attributable to NO release artifact: 'fix(ci): authenticate the federated externals sync ...' — no known artifact id or issue number in the subject, and no artifact's `landed:`/`verified-by:` names its PR (#1119: work landed, every artifact silent). That rule shipped ten commits ago in #1124, and this is the first time it has fired on real work. It fired on MINE, which is the right direction: I merged a CI fix with no artifact, and the gate refused to let the release plan stay silent about it. Fixed by creating the artifact, not by exempting the commit. RQ-62-FEDAUTH records the finding, which is worth more than the fix: THE ERROR MESSAGE ACTIVELY MISLEADS. "could not read Username for https://github.com" reads as a permissions failure. All seven siblings are PUBLIC, so an anonymous clone needs no credentials — git only prompts AFTER the transport refuses, and a throttled anonymous response on a tty-less runner surfaces as "No such device or address". The cause is a rate limiter on unauthenticated traffic, hardest from datacenter address space, which is where the self-hosted fleet lives. THE PASSES DO NOT PROVE THE FIX, recorded so nobody later claims they did. #1141 and #1142 passed WITHOUT it at 21:25; #1140 failed without it at 06:14; #1144 passed with it at 21:29. Every failure sits in one contiguous window and everything outside succeeds — the limiter eased on its own. The fix is still right for a reason those passes do not show: it removes the dependence on which side of a window a run lands. AN INTERMITTENT LIMITER IS WORSE FOR SIGNAL THAN A PERMANENT ONE. A job that flaps teaches maintainers to stop reading it — which is precisely what happened: I described this job's failure from memory twice in the org-wide review and was wrong both times. What the job got right and keeps: advisory so nothing was blocked, and it FAILS CLOSED — the non-vacuity guard was skipped rather than passing vacuously, the #1012 lesson working as designed. ARTIFACT_FLOOR re-derived at 519 with `rivet list`. Refs #1143, #1119, #1062 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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.
Merging #1144 turned main red on R10:
That rule shipped ten commits ago in #1124 and this is the first time it has fired on real work. It fired on mine — I merged a CI fix with no artifact, and the gate refused to let the release plan stay silent about it. Fixed by creating the artifact, not by exempting the commit.
The finding is worth more than the fix
The error message actively misleads.
could not read Username for 'https://github.com'reads as a permissions failure. All seven siblings are public, so an anonymous clone needs no credentials — git only prompts after the transport refuses, and a throttled anonymous response on a tty-less runner surfaces asNo such device or address. The cause is a rate limiter on unauthenticated traffic, hardest from datacenter address space, which is where the self-hosted fleet lives.The passes do not prove the fix
Recorded so nobody later claims they did:
Every failure sits in one contiguous window; everything outside it succeeds. The limiter eased on its own. The fix is still right for a reason those passes don't demonstrate — it removes the dependence on which side of a window a run lands.
An intermittent limiter is worse for signal than a permanent one. A job that flaps teaches maintainers to stop reading it — which is exactly what happened: I described this job's failure from memory twice in the org review and was wrong both times.
What the job got right and keeps: advisory so nothing was blocked, and it fails closed — the non-vacuity guard was skipped rather than passing vacuously (the #1012 lesson working).
Refs #1143, #1119, #1062