Uh oh!
There was an error while loading. Please reload this page.
chore: drop a committed .pyc, and ignore the class (backend#1602) - #204
Merged
Conversation
`scripts/__pycache__/standards-sync.cpython-314.pyc` was committed by a `git add -A` in #200 and reached `develop`. It is now riding the develop -> staging promotion in .github#203, which is how I noticed it. It is a build artifact and does not belong in the tree: version- and platform-specific (cpython-314, while CI runs 3.12), regenerated on every local run of the selftest, and a stale one silently shadows the source it was built from. Added a .gitignore covering the whole class rather than the one file that got caught -- `__pycache__/`, `*.py[cod]`, plus .DS_Store and .pytest_cache, which the same careless `add -A` would sweep in next. The file is also present on the #197 branch, which branched after #200; removed there too, so whichever lands first the artifact is gone and the other cannot reintroduce it. Selftest still passes (20 checks on this branch; #197 takes it to 27). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LukasWodka added a commit
that referenced
this pull request
Aug 10, 2026
Same artifact as .github#204, removed on this branch as well. This branch was cut after #200, so it carries the file; without this, merging #197 after #204 would put it straight back and the fix would look like it had held. The .gitignore is identical to #204's, so whichever merges first the other resolves cleanly. Selftest: 27 checks, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
saadqbal pushed a commit
that referenced
this pull request
Aug 11, 2026
…tes (backend#1602) (#197) * fix(standards): retry fresh-branch reads; refresh sha on rejected writes (backend#1602) Design rule 5: fresh refs are eventually consistent. On run 31373298821 (frontend-app leg) the contents read on a just-created branch transiently 404'd, the 404 was believed, and the sha-less PUT was rejected as 'Invalid request' — one flaky read failed a fleet run. remediate() now knows whether the base has the file: reads the base proves must succeed retry with backoff and fail closed if they never do; genuine absence is confirmed by a re-read; a 409/422-rejected write refreshes the sha and retries exactly once. Five new offline selftest checks pin the contract with a scripted gh stub (25 checks total). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(standards): a reused sync branch may honestly 404, and say so on a real conflict Two Bugbot findings on #197. 1. `expect_file` MEANS "a 404 here cannot be true" -- which holds only when the ref was cut moments ago from a base that has the file. That is the eventual consistency window the retry exists for. A REUSED branch (the 422 path) is a different situation: it may have been cut BEFORE CLAUDE.md existed on the base, so a 404 is honest and permanent. Passing file_on_base alone made the read retry five times and fail closed, so the sha-less create could never run and that repo was stuck forever. The old code read the 404 as absence and created the file, which was right here. expect_file is now `file_on_base and branch_is_fresh`. 2. The second-rejection message was UNREACHABLE. On attempt 2 the flow fell through to the generic return inside the loop, so the one failure worth distinguishing -- refreshed the sha and was rejected anyway, i.e. another writer is racing the branch -- was the one nobody could see. It now returns its own message, and the post-loop return is documented as a fail-closed backstop rather than dead code that would return None (i.e. SUCCESS). Selftest 25 -> 27. Mutation-verified both: reverting expect_file, and making the second-rejection branch unreachable again -- both CAUGHT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(standards): the reused-branch check asserted an end state and proved nothing Mutation-checking the previous commit caught its own test. Reverting the expect_file fix left the selftest GREEN, because the check asserted only "the file got created". With the bug present the read retries, swallows the scripted PUT response, reads its `{}` body as the file, and the run reaches the same end state by a different path. Same outcome, wrong reason -- so the check could not distinguish fixed from broken, in either direction. Assert the READ COUNT instead: 2 when a 404 on a reused branch is believed as absence, 5 when it is wrongly treated as the eventual consistency window. That is the thing the fix actually changes. Also catches the stub's exhaustion assertion and records it as a failure rather than letting it abort the whole selftest. Re-verified: reverting expect_file is now CAUGHT (reads=3, expected 2). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore: drop the committed .pyc here too (backend#1602) Same artifact as .github#204, removed on this branch as well. This branch was cut after #200, so it carries the file; without this, merging #197 after #204 would put it straight back and the fix would look like it had held. The .gitignore is identical to #204's, so whichever merges first the other resolves cleanly. Selftest: 27 checks, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
LukasWodka added a commit
that referenced
this pull request
Aug 27, 2026
…d#2637) (#359) * ci(conflict-gate): a conflicted PR reads red, not empty-green (backend#2637) A PR with a merge conflict against its base dispatches NONE of its `pull_request` workflows: GitHub cannot compute the merge ref those runs are keyed on. Every drift and source-of-truth guard is therefore silently inactive on exactly the PRs most likely to need it, and the rollup shows nothing red because nothing ran. Measured on model-zoo#206 while it was DIRTY against develop: 0 workflow runs on its head sha, one rollup entry (Cursor Bugbot, SUCCESS), and all seven of model-zoo/develop's required contexts absent. PRs #204 and #205 either side of it got their full matrix. Adds an org-wide sweep that writes a commit status onto each open PR's head sha - failure when conflicted, success when clear, pending when GitHub will not say - which is the only signal that can reach a PR with no merge ref. Not required anywhere yet, deliberately: a 30-minute sweep would leave a freshly-opened PR at "Expected - waiting" until the next run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(conflict-gate): a case that CRASHES is not a case that CAUGHT (backend#2637) Two mutations -- drafts skipped in plan(), and an unreadable PR list returning no error -- emptied a list the suite then indexed, so it died with an IndexError instead of reporting a FAIL. The harness correctly scored both as 'broke the harness' rather than caught: a traceback proves nothing about coverage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(conflict-gate): record the green-but-conflicted shape the watcher cannot see (backend#2637) backend#2257, measured live and CONFLICTING, carries 8 workflow runs and all eleven of backend/develop's required contexts present and SUCCESS -- computed against a merge base that no longer exists. bricked-prs.py reasons from an ABSENT required context, so with nothing missing it cannot see this PR at all. That is the case that justifies asking about mergeability directly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(conflict-gate): a status is written only when it would change something (backend#2637) GitHub caps statuses at 1000 per sha AND context. A 30-minute sweep is 48 writes a day onto an unchanged head, so a PR left open three weeks would exhaust the cap and every later write would 422 -- the gate going silent on exactly the stalest PRs, which are the ones most likely to have conflicted. The current state is read out of statusCheckRollup, which the PR list already returns, so this costs no extra API call. A truncated rollup omits our context, which reads as 'no status yet' and produces a write -- the safe direction. The case fold is load-bearing: GraphQL reports SUCCESS, the Statuses API takes success, and comparing unfolded would make every status look changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(conflict-gate): assert the workflow is ARMED, not merely present (backend#2637) Everything the suite asserted proved the SCRIPT was right; none of it proved anything RUNS it. Adds nine assertions parsing conflict-gate.yml as YAML (a "run:" line under a comment or an "if: false" greps identically to a live one) and six workflow mutations, so the harness now rewrites both files. The regression most likely to be made in good faith has its own mutation: someone asks why this does not run on PRs, adds a "pull_request:" trigger, and the gate becomes inert on exactly the conflicted PRs it exists for while looking more thorough. Rule 5 does not exempt a guarantee for being written in YAML. The baseline guard now covers both targets: a mutation left in the workflow by a killed run would become the next run's premise just as silently as one left in the script. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(conflict-gate): read the current status via REST, not the rollup (Bugbot, #359) Bugbot raised this as high on the previous head, and it was right. "gh pr list --json statusCheckRollup" resolves "commit.status" underneath, and GraphQL REFUSES that subfield on a PRIVATE repo unless the token also holds "actions: read" -- measured under backend#2157 and documented in bricked-prs.yml, which declares "permission-actions: read" for exactly this reason. This gate's mint deliberately holds only pull-requests:read and statuses:write, so the dedup added in c3b8279 would have made open_prs raise on every private repo in the org: each becomes COULD NOT EVALUATE and the sweep exits 2 having judged almost nothing. The trap was documented in a file I read while writing this one, which is the argument for measuring a narrow token rather than reasoning about it. Reads "GET /repos/{o}/{r}/commits/{sha}/status" instead. It reads commit statuses and nothing else, so the statuses permission already held covers it; it cannot be refused for a scope this job has no other use for; and it has no pagination cap to straddle. One GET per open PR, ~50 per sweep. The mint stays at two permissions. Two new mutations pin it: switching back to the rollup, and treating an unreadable current state as agreement (which would silently stop reporting whenever the status read flakes). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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 freeto 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.
Summary
scripts/__pycache__/standards-sync.cpython-314.pycwas committed by agit add -Ain #200 and reacheddevelop. It is now riding thedevelop → stagingpromotion in #203 — which is how I spotted it.It's a build artifact and doesn't belong in the tree:
cpython-314, while CI runs 3.12)Added a
.gitignorecovering the whole class rather than the one file that got caught —__pycache__/,*.py[cod], plus.DS_Storeand.pytest_cache/, which the same carelessadd -Awould sweep in next.The file is also present on #197's branch, which branched after #200. Removed there too, so whichever lands first the artifact is gone and the other can't reintroduce it.
Type
Chore
Test plan
python3 scripts/tests/standards-sync-selftest.py— 20 checks, 0 failed (fix(standards): retry fresh-branch reads; refresh sha on rejected writes (backend#1602) #197 takes it to 27)git ls-tree -r origin/develop | grep -iE '__pycache__|\.pyc$|\.DS_Store|\.egg-info|\.pytest_cache'— this was the only stray artifact in the treeChecklist
Note
Low Risk
No application or deployment logic changes—only version-control ignores and removal of a build artifact.
Overview
Repository hygiene: stops Python build artifacts and common local junk from being committed again.
Adds a root
.gitignorefor__pycache__/,*.py[cod],*$py.class, plus.DS_Storeand.pytest_cache/, with a short comment explaining why bytecode was ignored as a class rather than a single path.Per the PR scope, also drops the stray
scripts/__pycache__/standards-sync.cpython-314.pycthat had reacheddevelop(not shown in the diff snippet you have, but called out in the title/description).Reviewed by Cursor Bugbot for commit bcb9656. Bugbot is set up for automated code reviews on this repo. Configure here.