Repository navigation
pr-merge's re-fire of a refused pr-refine run pushes an empty commit that starts no pr-refine run #8244
Description
Refs: #8243
Summary
When the token broker refuses a pr-refine run as workflow-modified, pr-merge's scheduled re-fire (.github/scripts/pr-merge/refire-refused.mjs, run from the "Re-fire lane runs refused as workflow-modified" step in .github/workflows/pr-merge.yml) pushes an empty commit to the PR. That commit starts no pr-refine run, so the refused fix-docs pass never runs again on main's files.
Evidence
refire-refused.mjsheader: "a new head starts fresh pull_request events, which run main's files." The empty commit is made with the lanes App token through the Git Data API.pr-refine.yml'sfix-docsjob skips anypull_requestevent whose sender is the lanes App (format('{0}', github.event.sender.id) == vars.AUTOMATION_LANES_APP_SENDER_ID). An App push is such an event, so even before feat(pr-pipeline): run pr-refine once and mark a conflicted head with a status #8243 the empty commit'ssynchronizeevent skipped fix-docs.- After feat(pr-pipeline): run pr-refine once and mark a conflicted head with a status #8243,
pr-refine.ymlhas nosynchronizetrigger at all (types: [opened, reopened, ready_for_review]), so the push starts no pr-refine workflow run. - feat(pr-pipeline): run pr-refine once and mark a conflicted head with a status #8243 corrects the marker comment: it now says the push starts no pr-refine run, and that pr-refine runs again on a reopen or when a listed person dispatches it. The re-fire itself still does nothing for pr-refine. It does restart every other
pull_requestworkflow on the PR, both AI review lanes included.
Recommendation
Dispatch pr-refine.yml on re-fire: send a workflow_dispatch on refs/heads/main with pr-number, which runs main's files, instead of pushing an empty commit for the pr-refine lane. First check that check-trusted-trigger and the token broker accept a dispatch from the sender the re-fire would use (the lanes App or GITHUB_TOKEN). If they don't, drop the pr-refine entry from the re-fire table and leave the run to a person. Update refire-refused.test.mjs to match.
Activity
github-actions commentedon Oct 18, 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
Understood: when the token broker refuses a pr-refine run as workflow-modified, pr-merge's re-fire pushes an empty commit. That push starts no pr-refine run, because the fix-docs job skips events sent by the lanes App and #8243 removes the synchronize trigger. You propose dispatching pr-refine.yml on main with the PR number instead. If check-trusted-trigger and the token broker reject that sender, you propose dropping the pr-refine entry from the re-fire table. Either way, refire-refused.test.mjs is updated.
Nothing is missing. The first step is checking whether the broker accepts a dispatch from the sender the re-fire would use. I found no likely duplicates among the open issues.
Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 25, 2026
Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.
To hold this issue again, add
needs-human(orstatus: needs-decision) and say why in a comment.melodic-automation-lanes commentedon Oct 25, 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. 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 Oct 25, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: needs-decision; its comment says why.melodic-automation-lanes commentedon Oct 25, 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: Close as already resolved: the re-fire table in refire-refused.mjs has no pr-refine entry, so no empty commit is pushed for pr-refine.
Related work
Open questions
RECOMMENDED: Yes, close it. If the owner wants a refused fix-docs run re-dispatched on main, open a new issue scoped to that. Basis: .base/.github/scripts/pr-merge/refire-refused.test.mjs:210
RECOMMENDED: No. pr-refine.yml says pr-unblock-dispatch.yml sends the dispatch for fix-docs, and the broker's acceptance of a dispatch from the re-fire's sender is unverified. Leave it to a person unless the owner asks for more. Basis: .base/.github/workflows/pr-refine.yml:8
Sources read
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Oct 25, 2026
Closing as completed by #9039 (bd4b933), which took this issue's fallback. The re-fire table now holds only
pr-unblock.yml(.github/scripts/pr-merge/refire-refused.mjs:62-90), so pr-merge pushes no empty commit for pr-refine.refire-refused.test.mjs:210("a pr-refine.yml run is no longer read or re-fired") pins it. fix-docs is reached by workflow_dispatch from pr-unblock-dispatch (.github/workflows/pr-refine.yml:8,25). If a refused fix-docs run should be re-dispatched automatically, that is a new issue.