Skip to content

fix(ci): re-run ci-status on open lanes App pull requests when the kill switch is lifted #9522

Closed

Description

@kyle-sexton

Problem

While CLAUDE_LANES_DISABLED or CLAUDE_LANES_REPO_DISABLED is on, ci-status fails every lanes App pull request (pr-require-checks.yml lanes App step, added in #9508). Nothing re-runs ci-status when the switch is lifted, so open lane PRs stay red until a push or a manual re-run. Raised by poteto's review of #9508.

Done when

Lifting the kill switch leads to a ci-status re-run on each open lanes App pull request within one scheduled interval (for example from the scheduled reconciler), with no per-PR polling while the switch is on.

Activity

  1. added
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 23, 2026
  2. github-actions commented on Oct 23, 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: Knowable
    Flags: none
    Blocked by: none

    Understood: while the lanes kill switch is on, ci-status fails every lanes App PR. Nothing re-runs it once the switch is lifted, so those PRs stay red until a push or manual re-run. The goal is a ci-status re-run on each open lanes App PR within one scheduled interval, with no per-PR polling while the switch is on. The approach (for example hooking into the scheduled reconciler) is clear enough to start. A reader would first need to check how the reconciler tracks the switch state. No likely duplicates found among the open issues.

    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 23, 2026
  4. kyle-sexton commented on Oct 26, 2026

    @kyle-sexton
    MemberAuthor

    Builder: the Automation Lanes session builds this from the owner's machine. The fix edits .github/workflows, which the lanes App cannot push (patch-rules.json:3); that boundary stays. Its PR closes this issue. needs-human came off under the owner's 2026-10-26 rule (a person only for an intent or vision change, an implementation finding that alters intent or the primary design, or a HIGH/CRITICAL security issue); none applies. agent-ready stays off so the issue lane does not race the build.

  5. added
    status: confirmedA maintainer confirmed the item is real and in scope; ready to be worked.
    and removed
    status: needs-decisionAwaiting a human or maintainer judgment call.
    needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.
    on Oct 26, 2026
  6. kyle-sexton commented on Oct 26, 2026

    @kyle-sexton
    MemberAuthor

    Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.

    To hold this issue again, add needs-human (or status: needs-decision) and name which of the three applies.

  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.
    and removed
    status: readyTriaged, unblocked, and fully specified; eligible to pick up.
    on Oct 26, 2026
  8. melodic-automation-lanes commented on Oct 26, 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, 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).

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

    @melodic-automation-lanes
    Contributor

    The latest triage verdict holds nothing: the issue is at status: ready.

  10. added
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    and removed
    status: confirmedA maintainer confirmed the item is real and in scope; ready to be worked.
    on Oct 26, 2026
  11. melodic-automation-lanes commented on Oct 26, 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. 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: The scheduled reconciler re-runs pr-require-checks (so ci-status) once on each open lanes App pull request whose ci-status failed on the kill-switch step, on its first run after both switches read 'false'.

    Acceptance criteria

    • maintenance-reconcile-lost-runs/reconcile.mjs plans a re-run of the newest pr-require-checks run on the head of each open, non-draft lanes App pull request into main whose ci-status failed on the 'Fail a lanes App pull request its body or a member holds' step with the kill-switch error
    • The plan only runs when KILL_SWITCH is 'proceed' (reconcile.mjs:749), so no PR is read or re-run while either switch is on, and the added code makes no per-PR API call on that path
    • A pull request not authored by the lanes App (numeric id and type Bot), or one whose ci-status did not fail on that kill-switch error, is never re-run by this rule
    • The re-run is made once per head: a run already at attempt 2 is not re-run, and the existing cap of 3 in-flight re-runs and one-second write spacing still apply
    • The attempt-2 re-run of pr-require-checks gets its reconcile-rerun record artifact, as the existing RECORDED_UPSTREAMS path does, so pr-verify trusts it
    • A node test in the reconcile script's existing test file covers: switch lifted re-runs a kill-switch-failed lanes App PR, switch on re-runs nothing, a non-lanes PR and a run already at attempt 2 are skipped
    • The header comment of maintenance-reconcile-lost-runs.yml and the comment on the lanes kill-switch step in pr-require-checks.yml (about line 4678) say the reconciler re-runs ci-status once the switch is lifted
    • Any workflow edit keeps the repository's existing lint and workflow tests (including scripts/ci-lanes-pr-hold.test.sh) passing

    Dependencies

    • The change edits .github/workflows, which the lanes App cannot push (patch-rules.json:3); the Automation Lanes session builds it from the owner's machine, as kyle-sexton's first comment says

    Related work

    Sources read

    • .github/workflows/maintenance-reconcile-lost-runs.yml:3-63: runs every 30 minutes (cron 4,34), re-runs lost runs once at attempt 1, and stops when the kill switch is on
    • .github/workflows/maintenance-reconcile-lost-runs.yml:104-119: the kill-switch step feeds KILL_SWITCH=proceed to the plan step
    • .github/scripts/maintenance-reconcile-lost-runs/reconcile.mjs:749: the plan stops unless KILL_SWITCH is 'proceed'
    • .github/scripts/maintenance-reconcile-lost-runs/reconcile.mjs:107: RECORDED_UPSTREAMS lists pr-require-checks.yml, so its attempt-2 re-run gets a record
    • .github/workflows/pr-require-checks.yml:4602-4606: the lanes App step fails while a kill switch is on
    • .github/workflows/pr-require-checks.yml:4677-4679: the failing check and its error text, which says to re-run ci-status once both read 'false'

    Automated refinement by the lanes App. Intake triages the issue again with it.

  12. removed
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 26, 2026
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: 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.

    Type

    Fields

    No fields configured for Bug.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions