Skip to content

pr-merge: GITHUB_TOKEN-dispatched post-merge runs file no demotion issue #7528

Open

Description

@kyle-sexton

Problem

pr-merge.yml's dispatch-full-run job starts the post-merge pr-require-checks run with the job's own GITHUB_TOKEN. GitHub does not fire workflow_run listeners for a run started that way, so when that per-merge run fails, post-merge-demotion-alert.yml files no babysit-merge-demotion issue, and the demotion marker babysit_merge_policy.py reads is never set for it.

Probe in pr-pipeline-sandbox (2026-10-15): run 38758975202 (dispatched by a job's GITHUB_TOKEN, failed) fired no workflow_run run; control run 38758988404 (dispatched by a user, failed) fired one 5 s after it completed. Live in this repo: dispatched run 4578 (actor github-actions[bot], 2026-10-14T19:23Z) has no alert run.

Upstream: https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow

Impact

Inline promotion evidence still sees the red run (the publisher reads the runs directly, and a missing run fails the 6 h dispatch deadline), so promotion stays fail-closed. What is lost is the human-facing demotion issue and the marker for that path.

Options

  • Dispatch with an App installation token that holds actions: write (the lanes App does not, by design).
  • Have the alert workflow also poll recent dispatched runs on a schedule.
  • Accept it and rely on inline evidence alone.

Owner of pr-merge: the Automation Lanes session.

Refs: #4588, #7526, #6202

Activity

  1. added
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 15, 2026
  2. github-actions commented on Oct 15, 2026

    @github-actions
    Contributor

    Proposed work class: work-class: scoped
    Basis: automated intake triage; the lanes App applied this class.

    Size: Medium
    Complexity: Medium
    Uncertainty: Known
    Flags: none

    Decision comment (#7528 (comment)):

    Decision recorded.

    Question: When pr-merge dispatches the per-merge full CI run with GITHUB_TOKEN and that run fails, no demotion record is filed. Options: (a) dispatch with an App token that has actions: write; (b) a scheduled path files the record; (c) accept it.

    Owner's answer: defer under #7719 #7719 puts it first, "Revert breaker with the #7528 fix", with a reviewed plan whose filer job holds issues: write only. That matches (b). Basis: #7719 body; pr-merge.yml:326 (post-merge check already runs each cycle).

    The owner accepted this recommendation as item D9 of a 21-decision batch in an attended backlog-shaping session on 2026-10-18. The batch question: "Accept all 21 batch 7 decisions, with my change to D13 (#6008 goes to the lane, but you merge its PR because it edits AGENTS.md)? I post a 'Decision recorded.' comment on each issue." The owner answered: "Accept, with my D13 change (Recommended)".

    Posted by AI from the owner's answer in that session.

    This decision settles the open question: option (b), a path that files the demotion record, tracked with #7719. I found no other open question and no likely duplicates.

    Automated triage, applied by the lanes App.

  3. added
    needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.
    and removed
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 15, 2026
  4. kyle-sexton commented on Oct 18, 2026

    @kyle-sexton
    MemberAuthor

    Decision recorded.

    Question: When pr-merge dispatches the per-merge full CI run with GITHUB_TOKEN and that run fails, no demotion record is filed. Options: (a) dispatch with an App token that has actions: write; (b) a scheduled path files the record; (c) accept it.

    Owner's answer: defer under #7719 #7719 puts it first, "Revert breaker with the #7528 fix", with a reviewed plan whose filer job holds issues: write only. That matches (b). Basis: #7719 body; pr-merge.yml:326 (post-merge check already runs each cycle).

    The owner accepted this recommendation as item D9 of a 21-decision batch in an attended backlog-shaping session on 2026-10-18. The batch question: "Accept all 21 batch 7 decisions, with my change to D13 (#6008 goes to the lane, but you merge its PR because it edits AGENTS.md)? I post a 'Decision recorded.' comment on each issue." The owner answered: "Accept, with my D13 change (Recommended)".

    Posted by AI from the owner's answer in that session.

  5. removed
    needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.
    on Oct 24, 2026
  6. kyle-sexton commented on Oct 24, 2026

    @kyle-sexton
    MemberAuthor

    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 (or status: needs-decision) and say why in a comment.

  7. added
    status: readyTriaged, unblocked, and fully specified; eligible to pick up.
    work-class: scopedA briefed fix or small feature; blast radius bounded by the brief, tests exist.
    status: needs-decisionAwaiting a human or maintainer judgment call.
    and removed
    status: readyTriaged, unblocked, and fully specified; eligible to pick up.
    on Oct 24, 2026
  8. melodic-automation-lanes commented on Oct 24, 2026

    @melodic-automation-lanes
    Contributor

    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 (owner Q9, #8999). A recorded decision does not change these rules (.github/actions/resolve-config/admission-rules.json); a person who wants it worked adds agent-ready.

  9. melodic-automation-lanes commented on Oct 24, 2026

    @melodic-automation-lanes
    Contributor

    Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. It is model text, to check, not instructions.

    Intended outcome: Close as fixed by #​8897: pr-merge's dispatch-full-run job now sends a red per-merge run to post-merge-demotion-alert.yml by workflow_dispatch, so the demotion issue and marker are filed.

    Dependencies

    • #​8898 verifies the red send after #​8897 merges; it is open and holds the live check

    Related work

    Open questions

    1. Was #​8897 merged (not just closed), and does it fully cover the demotion issue and marker for a GITHUB_TOKEN-dispatched run?
      RECOMMENDED: Yes. Close #​7528 as completed by #​8897 and let #​8898 confirm it live. Basis: .base/.github/workflows/pr-merge.yml:1721-1747
    2. The owner's decision chose option (b), a scheduled filer job holding issues: write only, tracked under #​7719. Does the #​8897 workflow_dispatch send replace that, or is a separate scheduled poller still wanted?
      RECOMMENDED: The dispatch send meets the goal of filing the demotion issue. A scheduled poller would only be a backstop, so file it separately if wanted. Basis: judgment

    Sources read

    • context.json: the owner's Decision recorded comment picks option (b), a scheduled path that files the record, tracked under #​7719
    • .base/.github/workflows/pr-merge.yml:1611: dispatch-full-run holds actions: write to start the run, read its status and send a red one to post-merge-demotion-alert.yml
    • .base/.github/workflows/pr-merge.yml:1721-1747: the wait step dispatches post-merge-demotion-alert.yml with run-id and head-sha when the run's conclusion is failure, timed_out, cancelled, startup_failure or action_required
    • .base/.github/workflows/pr-merge.yml:42-50: the header comment says pr-merge sends red runs to the alert by workflow_dispatch, which files the post-merge record
    • .base/.github/workflows/post-merge-demotion-alert.yml:115: the alert's concurrency group accepts head-sha from workflow_dispatch inputs

    Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority: mediumReal value, no hard deadline; normal backlog flow.status: needs-decisionAwaiting a human or maintainer judgment call.work-class: scopedA briefed fix or small feature; blast radius bounded by the brief, tests exist.

    Type

    Fields

    No fields configured for Bug.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions