Repository navigation
pr-standards needs:issue is a false positive for v2-based PRs because the runner uses the dev copy of the workflow #51057
Description
Description
needs:issue is still applied to every PR that targets v2, even when the description references an issue exactly as the template asks. #43964 fixed this by falling back to a PR-body check, and that fix is in .github/workflows/pr-standards.yml on v2 since 2026-08-25 — but not on dev, which is the default branch, and pull_request_target executes the default branch's copy of the workflow. So the corrected check lives in the tree that ships and is absent from the copy that actually runs.
Evidence from the run on PR #51052 (base v2, opened today): the script echoed by its check-standards job contains if (linkedIssues === 0) and zero occurrences of hasBodyIssueRef, which is dev's copy. Consequence right now: 141 open PRs carry needs:issue, among them #51035 and #51043, whose description carries Closes #51041.
Why the GraphQL check alone cannot work here: closingIssuesReferences is only populated for PRs that target the repository default branch, so a v2 PR reports totalCount 0 however well-formed its description is.
What dev needs is the same nine lines #43964 added on v2.
Plugins
Not applicable, this is about the CI workflow.
OpenCode version
Not a product version: .github/workflows/pr-standards.yml, dev copy as of 0f54984.
Steps to reproduce
- Open or edit any PR whose base is
v2withFixes #<issue>inside the### Issue for this PRsection. - Wait for
pr-standards→check-standards. - The PR gains
needs:issueand the "doesn't have a linked issue" comment even though the reference is there.
Operating System
Any; the check runs on ubuntu-latest and the defect is branch-independent.
Terminal
Not applicable.
Activity
Veld101 commentedon Sep 27, 2026
Independent confirmation from an affected contributor — my six
fix(...)PRs againstv2all carryneeds:issuewithclosingIssuesReferences0, while the same style of body links fine ondev:Closes #49216Closes #51014Closes #50426Closes #48259Closes #50338Closes #50474Closes #50807Closes #50722Two things I did not see stated, which may be worth adding to the description:
Only
fix-titled PRs are hit.check-standardsreturns early fordocs/refactor/feattitles (skipIssueCheck), and that branch also removes the label. Sofeat(tui): …againstv2is fine andfix(tui): …is not. That is why it reads as inconsistent rather than universal — every PR in the table above is afix.The label is sticky once applied. The only
removeLabel('needs:issue')paths are theskipIssueCheckbranch and thelinkedIssues > 0case, which av2base can never satisfy, and the job only triggers onopened/edited/synchronize. So after fix(ci): apply the PR body issue fallback on the default branch copy #51058 lands, the ~141 already-labeled PRs will not clear themselves: each author has to push a commit or edit the PR, or a maintainer removes the labels in bulk. Aworkflow_dispatchbackfill (or a note in the contributing guide) would close that gap.Tsuki-hash commentedon Sep 27, 2026
@Veld101 both additions hold up against the workflow source, and the counts are worse than the 141 I quoted: as of today 181 open PRs carry
needs:issue, 169 of themfix-titled againstv2. Your read of the mechanism is exactly right:skipIssueCheck(pr-standards.yml:112-115) coversdocs/refactor/featand also removes the label, which is why the pattern looks like afix-only bug rather than a blanket one.removeLabel('needs:issue')paths are that branch and the fall-through after the linked check (:161), and the job triggers only onopened/edited/synchronize. With av2base the fall-through was unreachable before fix(ci): apply the PR body issue fallback on the default branch copy #51058, so every labeled PR stays labeled until its author edits or pushes.One practical nuance for the already-labeled set: once #51058 is live, a re-trigger is enough - any edit or push re-evaluates the body and takes the clear path, so
fixPRs onv2do not need a new commit with new content, just an event. Whether to also add a backfill (bulk label removal, or aworkflow_dispatchpath) is the maintainers' call rather than something to fold into the fix; a dispatch run has nopull_requestpayload, so that script needs its own listing path.opencodejr commentedon Oct 28, 2026
Thanks for the detailed report. I copied the
check-standardsscript out of the workflow and ran it against a mocked GitHub API. The test PR was afix(...)PR on basev2withCloses #51041in the### Issue for this PRsection, withclosingIssuesReferencesreturning 0 as you described.pr-standards.ymlat0f54984(the copy you reported): it addedneeds:issueand posted the "doesn't have a linked issue" comment, so it reproduced.dev(fa1260d): afterv2was promoted todev, the workflow is nowtriage-pr-standards.ymland includes the PR-body fallback from fix(ci): check PR body for linked issue on non-default branches #43964 (hasBodyIssueRef). The same PR passes andneeds:issueis removed.So this looks fixed on the default branch now. PRs that were labelled before the change may keep a stale
needs:issueuntil their next edit or push, as noted on #51058.Related: #51970 (the same report, closed as a duplicate of this one), #43964 (the original fix on
v2), #51058 and #51971 (backport PRs).The bot will close this issue in 1 day unless you reply that it still happens.
Tsuki-hash commentedon Oct 28, 2026
Thanks for verifying this. The fix on latest
dev(thetriage-pr-standards.ymlwith thehasBodyIssueReffallback from #43964) matches what I reported, and I am happy with that resolution. The stale-label note for previously labelled PRs is already tracked in #51058, so it does not need to block this one. Feel free to close this issue.opencodejr commentedon Oct 29, 2026
Closing this as completed, since there's been no reply for a day. With
pr-standards.ymlat0f54984, afix(...)PR withCloses #...in its description got a falseneeds:issue. With the currentdevworkflow (triage-pr-standards.ymlatfa1260d) it doesn't, because the PR-body fallback from #43964 is now on the default branch. This is a CI workflow, so the fix already applies to new runs and doesn't need a release. PRs labelled before the change may keep a staleneeds:issueuntil their next edit or push, as noted on #51058.If you still see the false label on a PR after editing or pushing to it, please comment here or open a new issue with a link to the run. Thanks for the clear write-up and the evidence.