Repository navigation
fix(pr-pipeline): resolve pr-verify's earlier fail-note threads when a later head passes #13038
Description
No related issue: found while driving PRs; repros #12962 and #12974
Problem
When pr-verify FAILs a head, verify-notes.mjs opens one review thread per note (first line <!-- pr-verify:fail-note -->). When a later head passes, those threads stay unresolved, and an unresolved thread blocks the merge.
The clearing step exists but only runs inside an address-feedback round: staleVerifyNotes (.github/scripts/pr-unblock/address-feedback.mjs:208-224) finds the notes a pass superseded, and publish-feedback.mjs resolves them as the lanes App. A pass on its own never triggers that round, so the notes clear only if a fix round happens to run after the pass and completes.
Repros:
- refactor(ai-briefing): resolve the view medium through the shared resolver #12962: pr-verify passed head 9ee1ade (artifact
pr-verify-12962-9ee1ade2…-pass-notes, 2026-11-03T23:04Z). The round after it failed at publish (fixed since by fix(pr-pipeline): accept feedback-already-addressed from publish-feedback #13016), so its two fail-note threads stayed open until the owner resolved them by hand. - fix(work-items): skip a create-item that duplicates a sibling under the same parent #12974: pr-verify passed head b5a5e45 (artifact
pr-verify-12974-b5a5e45c…-pass-notes). Four fail-note threads from head a113b95 (PRRT_kwDOTCGFQM6zXzyQ,…XzzN,…Xz0Y,…Xz1a) stay open on an armed PR; its last address-feedback round ran at 00:37Z, and no later round has run.
Each time, the PR waits on the owner for threads already settled. Agent sessions cannot resolve them either: the auto-mode classifier refuses a session's resolve of a verifier's thread.
Done when
- When pr-verify passes a head, it resolves that PR's earlier fail-note threads itself (the
staleVerifyNotesset for that head), through the lanes App token. They are its own threads, so no person is involved. A test shows a pass at a later head resolves the earlier notes and leaves notes on the passing head itself alone. - A one-time count of open PRs that carry settled fail-note threads today (unresolved notes on a head older than a passing head), reported on this issue, so they can be cleared once the fix lands.
Notes
- Owner lane: laptop Lane 3 (pr-verify), alongside ci(pr-verify): add the capture job that drives the affected app (S7 of #8651) #12232. The change touches
.github/, so it is pushed from a host session.
Activity
kyle-sexton commentedon Nov 4, 2026
Claimed by lane 3 (hub assignment H15). Plan: on a pr-verify pass, resolve that PR's superseded fail-note threads (the staleVerifyNotes set) with the lanes App token. Add a test showing a pass at a later head resolves the earlier notes and leaves the passing head's own notes alone. Then post the one-time count of open PRs that carry settled fail-note threads.
github-actions commentedon Nov 4, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
#13038 (comment)
This decision settles the open questions. The fix goes in the existing pass-only round, and done-when 2 is already met. What remains is to check whether #12974 hit the same publish failure that #13016 fixed, or a different skip condition. Then add a test that a pass at a later head resolves earlier fail-notes and leaves notes on the passing head alone. The work is a host-run step.
Automated triage, applied by the lanes App.
kyle-sexton commentedon Nov 4, 2026
Done-when 2, one-time count at 2026-11-04T02:0xZ: 0 of 21 open PRs carry an unresolved pr-verify fail-note thread, so there are no settled notes to clear once the fix lands. Method: one GraphQL read of every open PR's review threads, counting unresolved threads whose first comment opens with
<!-- pr-verify:fail-note -->. Marker check: the repro #12974's four fail-note threads match it, and all four are now resolved.melodic-automation-lanes commentedon Nov 4, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited; it carries host-run. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Nov 4, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.3 remaining items
melodic-automation-lanes commentedon Nov 4, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: Find why the existing pass-only resolve round did not clear the #12962 and #12974 notes, fix that gap, and test that a later-head pass resolves earlier notes and leaves the passing head's own notes alone.
Related work
Open questions
RECOMMENDED: Treat the work as finding and fixing that skipped condition, not as adding a new resolver. Candidates are a PR that is not on a lanes App pull request, a head that moved before the pass was read, or a dispatch gate such as the open-at-head check at verify-notes.mjs:251-276. The next step is to read the logs of those two pass runs. Basis: .github/scripts/pr-unblock/verify-notes.mjs:37
RECOMMENDED: Keep the dispatch to pr-unblock, where the lanes App token is available, and fix the gap there, unless the owner wants the resolving moved into the pr-verify job. Basis: .github/scripts/pr-unblock/verify-notes.mjs:44
RECOMMENDED: Yes, drop it from the criteria. The comment gives the count and the method. Basis: judgment
RECOMMENDED: Check whether each was merged. If 10474 merged and the repro still failed, scope this issue as a regression fix for the failing condition. Basis: 10474
Sources read
To answer, post a comment that starts with this line:
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Nov 4, 2026
Cause check (hub H16): the #12974 notes stayed open because the dispatcher skipped the pass-only round. It was not the publish failure #13016 fixed.
post-verify-notesfound#12974: 4 open fail-note thread(s) the pass-notes at b5a5e45c… may supersedeand set the pass head.dispatchthen skipped:pr-unblock.yml run 41738844371 for address-feedback is not done yet. That round ran 23:24:06Z to 23:34:36Z.VERIFY_PASS_HEADempty.address-feedback-selectloggedskip: 0 kept thread(s), 0 earlier round(s), andpublish-feedbackwas skipped. It never reached publish, and fix(pr-pipeline): accept feedback-already-addressed from publish-feedback #13016 (01:17Z) came later.The fix (#13046) is in the dispatcher: a pass-only dispatch is no longer dropped while a round is in progress, and pr-unblock's per-PR concurrency group queues it. Resolving stays in the pr-unblock round as the lanes App, and the pr-verify job gets no new token.
kyle-sexton commentedon Nov 4, 2026
Answers to the refinement's open questions. Each is settled by evidence, not an owner decision:
verify-notes.mjs:44, the job's own token cannot resolve threads. fix(pr-pipeline): resolve superseded pr-verify fail-notes when a round is in progress #13046 gives pr-verify no new token.kyle-sexton commentedon Nov 4, 2026
Decision recorded. Fix the gap in the existing pass-only pr-unblock round rather than move thread resolution into the pr-verify job; done-when 2 is already met (0 of 21).
Agent choice, not an owner answer.
Which condition made the pass-only path skip refactor(ai-briefing): resolve the view medium through the shared resolver #12962 and fix(work-items): skip a create-item that duplicates a sibling under the same parent #12974? Accept the RECOMMENDED answer: find and fix the condition that skipped, and add no new resolver. One correction: the Problem section says a pass never triggers a round, but the code has a pass-only round since fix(pr-pipeline): resolve stale pr-verify fail-note threads when a later head passes #10474 (
verify-notes.mjs:37-44). The body's refactor(ai-briefing): resolve the view medium through the shared resolver #12962 repro also says a round ran after the pass and failed at publish, which fix(pr-pipeline): accept feedback-already-addressed from publish-feedback #13016 fixed.fix(work-items): skip a create-item that duplicates a sibling under the same parent #12974's last round, at 00:37Z, also ran before fix(pr-pipeline): accept feedback-already-addressed from publish-feedback #13016 merged. So the builder first checks whether fix(work-items): skip a create-item that duplicates a sibling under the same parent #12974 hit the same publish failure before fix(pr-pipeline): accept feedback-already-addressed from publish-feedback #13016:
findStaleNotesprinted (is not open at head,no review comment, or a count of open fail-note threads), or through no line when the PR is not a lanes App PR. If it wrotepass-head-sha, the dispatch job's log shows whether the round was skipped for an active round, ado-not-mergehold, or a replaced dispatch. Fix that condition and test it.This record does not claim that fix(pr-pipeline): accept feedback-already-addressed from publish-feedback #13016 fixed the bug; the run logs decide.
Basis:
.github/scripts/pr-unblock/verify-notes.mjs:41("the dispatch job then sends pr-unblock.yml, whose publish-feedback job").verify-notes.mjs:254,:259,:272,:276(findStaleNotesand its three log lines).verify-notes.mjs:345(pass-head-sha=output).b4a72bc315, 2026-11-04T01:17:07Z, "fix(pr-pipeline): accept feedback-already-addressed from publish-feedback (fix(pr-pipeline): accept feedback-already-addressed from publish-feedback #13016)".verify-notes.mjs:262-268(a non-App PR returns false).f073b3e5b4(fix(pr-pipeline): resolve stale pr-verify fail-note threads when a later head passes #10474), Known limits.Resolve inside the pr-verify job, or keep the dispatch to pr-unblock? Accept the RECOMMENDED answer: keep the dispatch to pr-unblock, where the lanes App resolves the threads. Done-when 1 still sets the outcome: a pass at a later head resolves the earlier notes as the lanes App, and a test shows that the notes on the passing head stay open. The existing round is how that outcome is met. Done-when 1 read literally would hand the lanes App token to the pr-verify job, which this record avoids.
Basis:
verify-notes.mjs:44("Resolving a thread takes more than this job's token holds.")..github/workflows/pr-unblock.yml:19-23("After a pr-verify pass at a PR's head that left fail-note threads open, it sends one with verify-pass-head: a pass-only round, ... and the reply job resolves them as the lanes App").Is done-when 2 already complete? Accept the RECOMMENDED answer: yes, so drop it from the remaining work.
Basis: kyle-sexton's lane-3 comment of 2026-11-04T02:03:41Z on fix(pr-pipeline): resolve pr-verify's earlier fail-note threads when a later head passes #13038 ("0 of 21 open PRs carry an unresolved pr-verify fail-note thread"), which states its method.
Did fix(pr-pipeline): resolve stale pr-verify fail-note threads when a later head passes #10474 or fix(pr-unblock): resolve a fail-note thread a same-head pass superseded #11889 already deliver this? Accept the RECOMMENDED answer: fix(pr-pipeline): resolve stale pr-verify fail-note threads when a later head passes #10474 merged, so this is a failure in a path that exists, not a missing feature, and neither PR closes this issue.
f073b3e5b4("resolve stale pr-verify fail-note threads when a later head passes"). It added the pass-only round:pass-head-sha,staleVerifyNotesandverify-pass-head.94b8b684d0("resolve a fail-note thread a same-head pass superseded"). That covers the same-head case, not the earlier-head notes here.7a18685f2c(fix(pr-unblock): clear superseded fail notes on trusted-author PRs after a pass #10620),f88289b0a0(fix(pr-unblock): let a pass-only round with nothing to resolve clear its stop #10724),25dbbc535e(fix(pr-pipeline): recover failed feedback dispatches and unstrand pass-only rounds #11436).So work proceeds as decided in 1.
Basis:
git log origin/main --grepfor those numbers, run this session.Route: host-run, status: confirmed, builder laptop Lane 3 (pr-verify)
kyle-sexton commentedon Nov 4, 2026
Closed by lane 3 with this record.
staleVerifyNotesas the lanes App. Tests:feedback-dispatchandpublish-feedbacksuites 361 pass. Negative controls fail without the fix, and when notes on the passing head would be resolved. CI: both Claude review lanes 0 findings, ci-status green.