Repository navigation
fixed-in-PR: a label for an issue whose fix is already written - #825
Merged
Merged
Conversation
GitHub closes a linked issue when its PR reaches the DEFAULT branch. Here that is `main`, while the work merges to `development`, and merges to `main` are infrequent. So between a merge and a release an issue is fixed and still open, and nothing in the repository says so. The mechanism itself is sound: across the project's life 139 declared closes produced 5 that slipped. It is release-gated, not broken, and it was worth establishing that before adding anything -- the backlog was not caused by it. `fixed-in-development` is applied at merge and the release closes everything carrying it in one pass. Closing at merge stays a reasonable choice for a defect nobody outside is waiting on; it is only misleading for one somebody is. scripts/triage.py now lists every issue a merged PR declared that is neither closed nor labelled, and names three outcomes rather than two. The third is the reason the list is candidates and not fixes: #611 was credited to #656 and its hang is handled by a `--deselect` in scripts/test.sh at the very rank count the issue reports. The tool finds exactly that one today. Underworld development team with AI support from Claude Code
… all The label was named for the gap between a merge and a release, and that framing made the tool scan merged PRs only. It found one issue. Scanning open PRs as well finds four more, and those are the ones that matter: #785 carries the fix for #783 and #784 and cannot merge, because its base branch has no PR of its own. On the day the label was added, four of the five issues it applied to were in that state. So the label says the fix is written, and nothing more. Which PR, and whether it has merged, lives in the issue and in this tool's output, where it can be kept true -- a label cannot be. The merge-to-release half still holds: GitHub closes a linked issue on a DEFAULT-branch merge and that is `main`, reached infrequently here. 139 declared closes across the project's life produced 5 that slipped, so the mechanism is release-gated rather than broken, and it was worth establishing that before adding anything. Underworld development team with AI support from Claude Code
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The base-branch filter causes valid fixes in merged stacked PRs to disappear from triage output.
Review effort: Balanced
Findings: 1
What changed in this PR
Adds fixed-in-PR tracking for open issues whose fixes exist but remain unreleased.
Changes:
- Reports unlabelled issues declared fixed by open or merged PRs.
- Documents the label’s workflow and meaning.
- One bug remains: merged stacked PRs targeting non-development branches are excluded.
| File | Description |
|---|---|
scripts/triage.py |
Adds detection and reporting for written fixes. |
docs/developer/guides/adversarial-review.md |
Documents the new issue-triage label. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…h labels The guide conflict resolves to development's side wholesale. Its verdict table now carries the label lifecycle (`fixed-in-PR` while the PR is open, `fixed-in-development` once it merges, closed at release) and it already has the triage.py pointer and the mark-on-a-probe rule, so the paragraph on this branch was superseded rather than merged -- it described one label for two situations, which is no longer the policy. scripts/triage.py follows. It knew `fixed-in-PR` only, so an issue correctly flagged `fixed-in-development` would have been reported as having no label. Development had already excluded those from the probe set, which is the cleaner fix; what remained was the hint, which named one label for both states. There are now LABEL_IN_PR and LABEL_IN_DEV, and the hint names the one that fits the declaring PR -- open, merged, or already released. Two retry gaps found while running it. `gh` reports a short read from the API as "unexpected end of JSON input" and exits non-zero, so it has to be listed as transient alongside the 502s rather than caught at the parse; and gh_json now retries a response that parses badly despite a zero exit. Both are the same class: this endpoint is unreliable and the tool is meant to be run often. Underworld development team with AI support from Claude Code
…lopment A stacked PR merged into its feature base holds a written fix that has not reached development, and the base filter dropped it from FIX ALREADY WRITTEN (review on #825). Every merged PR is now considered; one whose merge commit is on origin/development reads as merged, and one whose base has not landed reads 'merged to <base>' with the fixed-in-PR outcome. Checked on the merged stacked PRs: #792 (feature/describe-render, since merged) reads as on development, #589 (bugfix/fault-clip-boundary) does not. Underworld development team with AI support from Claude Code
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.
Replaces #822, which named the label
fixed-in-development. The rename is not cosmetic — it changed what the tool looks for, and the first framing was wrong about the common case.Why not
fixed-in-developmentThat name framed the problem as the gap between a merge and a release, so the tool scanned merged PRs only. It found one issue.
Scanning open PRs as well finds four more, and those are the ones that matter:
Four of five are in an unmerged PR. #785 carries the fix for #783 and #784 and cannot merge — its base
feature/forward-parallelhas no PR of its own, so the whole stack (#785 → #789 → #795 → #800) has nothing to merge into.fixed-in-developmentwould have been wrong for every one of them.What the label says, and what it does not
It says the fix is written. It does not say which PR, or whether that PR has merged — that lives in the issue and in
scripts/triage.py, where it can be kept true. A label cannot be.The merge-to-release half still holds: GitHub closes a linked issue on a default-branch merge, and that is
main, which this project reaches infrequently. Worth recording that the mechanism is not broken — across the project's life 139 declared closes produced 5 that slipped. It is release-gated, and establishing that mattered before adding anything, because the backlog was not caused by it.Three outcomes, not two
#611 is the standing example of the third and the reason the tool reports candidates rather than fixes. #656 was credited with closing it; the hang is actually handled by
scripts/test.sh:289, a--deselectat the np=4 pass — the rank count the issue reports hanging at. A close-or-label tool would have labelled it and the hang would have gone quiet for good.Rolled out
Label created, and applied to #783, #784, #788 and #791, each with a line in the issue naming its PR and saying why it cannot land. #611 deliberately left bare.
Underworld development team with AI support from Claude Code