chore(pr-pipeline): verify the per-merge red send to the alert after #8897 merges

@kyle-sexton

The pr-pipeline README ("Changing this config") requires this tracking issue. A merged run is the only way to exercise this change.

Check

After #8897 merges, find the first per-merge full run that fails. That is a pr-require-checks run on main that github-actions[bot] dispatched and that concludes failure. For that run, confirm:

The dispatch-full-run job of pr-merge.yml logs run <id> completed: failure and sends that id with no error.
A post-merge-demotion-alert run starts with event workflow_dispatch. Its Read the failed run step accepts the run and writes outputs.
The alert job waits for pr-merge's re-run, up to 40 minutes, and starts no re-run of its own. It then files the record and its fix issues, or comments on an existing record.
report-red-main runs and reports a confirmed red, or reports "not confirmed" when no re-run finished.

If the send or the read is refused, the per-merge path is dead and the issue's original gap is back.

Owner: @kyle-sexton

Open question for the owner

In the 7 days to 2026-10-21, 22 per-merge runs ended red on attempt 1 and never got a re-run. Only 7 reached attempt 2. The likely reason is that post-merge-dispatch re-runs only lane-dispatched runs (--lane-merges-only); this is not verified. After #8897, each such red waits 40 minutes, then files a needs-human record and fix issues from attempt 1 alone, under the existing "a re-run that does not finish still files" rule. The red-main report never confirms one.

The options:

(a) Accept this.
(b) Extend the post-merge-dispatch re-run to every red run that pr-merge dispatched. That is a change to the re-run logic, outside fix(pr-pipeline): report red per-merge full runs to the red-main alert #8897.

Proposed work class: none

Size: Small
Complexity: Low
Uncertainty: Knowable
Flags: none
Blocked by: none

Decision recorded.

Question: What is left of this issue after #8968's --judge-run?

Answer (owner, 2026-10-22, Issue Triage session): "Also go w/ recommendations" (dictated), accepting the recommendation below.

Recommendation accepted: keep this issue only for the live check of the filing path and report-red-main (needs a red that persists). The in-set flake that stays red past the 40-minute wait is split to its own Automation Lanes issue for pr-merge's post-merge re-run selector (--lane-merges-only, .github/workflows/pr-merge.yml:173); the alert starts no re-run by design (post-merge-demotion-alert.yml:47-50). The wait itself is #9013.

#8898 (comment)

That decision settles the open questions. What remains is observing a per-merge red on main that persists through the 40-minute wait, then confirming the filing path and report-red-main. That depends on a real red occurring over time, so a maintainer or a later run has to confirm it.

_{Automated triage. A maintainer reviews it.}

fix(pr-pipeline): report red per-merge full runs to the red-main alert (

This was generated by AI during an attended run.

Live check after #8897: seven per-merge full runs ended red between 20:37Z and 03:40Z. The send and the read work, and design (b) suppressed every filing correctly. The filing path has not run yet.

red run	alert run	filed	main recovered by
39672238204 (`81d3f7f`, #8897's own merge)	39673266383	none	39677533245 @0ee645a2ab
39673287462	39674440650	none	39678657645
39674459547	39675604147	none	39679767370
39687691467	39688650626	none	39689621793
39688664364	39689605309	none	39689621793
39698917607	39699716986	none	39702927553
39709317854	39710085033	none	39710095388

Against the checks above:

Send: each dispatch-full-run job logged run <id> completed: failure, with no error, and an alert run with event workflow_dispatch started within seconds.
Read and wait: Read the failed run accepted every run. Each alert waited the full 40 minutes, logged the re-run of <url> did not finish within 40 minutes: judging attempt 1, and started no re-run. Every red run is still at attempt 1.
File: every alert logged main already recovered: run <id> at <sha> passed on main after it, so nothing filed. No record issues, no fix issues, no duplicates.
report-red-main was skipped all seven times. That is correct under design (b): the job's condition is needs.alert.outputs.recovered != 'true'. Check 4's expectation predates design (b).

Not yet verified: the filing path (check selection, record, fix issues) and the report job. They need a red that persists through the 40 minutes. Leaving this open for that.

Failures: the first three were real (align.test.sh join Guest 1 -> 403, after #8921, fixed by #8933). The other four look like flakes in planning ui.test.sh and packet-seal.test.sh. Under design (b), a flake that recovers is never filed.

Waste: the 40-minute wait runs before the recovery check, so each alert ran 40 minutes even though main recovered 8 to 30 minutes after the red. Follow-up filed separately.

Decision recorded.

Question: What is left of this issue after #8968's --judge-run?

Answer (owner, 2026-10-22, Issue Triage session): "Also go w/ recommendations" (dictated), accepting the recommendation below.

Recommendation accepted: keep this issue only for the live check of the filing path and report-red-main (needs a red that persists). The in-set flake that stays red past the 40-minute wait is split to its own Automation Lanes issue for pr-merge's post-merge re-run selector (--lane-merges-only, .github/workflows/pr-merge.yml:173); the alert starts no re-run by design (post-merge-demotion-alert.yml:47-50). The wait itself is #9013.

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.

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).

The latest triage verdict holds nothing: admission moved the issue to status: needs-decision; its comment says why.

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 this issue once one per-merge red on main persists through the 40-minute wait and the alert's filing path and report-red-main are confirmed on that live run.

Dependencies

A real per-merge red on main that stays red through the 40-minute wait; no test can force it unattended.
#9013 covers the wait itself (per the owner's decision comment).

Related work

ci(pr-pipeline): alert when pr-merge's post-merge check stays unreadable #9170 (related): alerting on unreadable post-merge checks in the same pr-pipeline path
chore(pr-pipeline): pr-merge dispatch and read-token review follow-ups #9355 (related): pr-merge dispatch and read-token follow-ups for the same path
pr-merge: GITHUB_TOKEN-dispatched post-merge runs file no demotion issue #7528 (related): earlier gap: dispatched post-merge runs filed no demotion issue; this issue verifies the fix

Open questions

Should this issue stay open as a passive watch for a persistent red, with a maintainer posting the live-run evidence, instead of being worked by an unattended lane?
RECOMMENDED: Yes: keep it open, held for the observation. A lane cannot cause or wait for a red that persists, so it has no checkable criteria. Basis: Owner decision comment 2026-10-22 and the 2026-10-22 verification comment: all 7 reds recovered, so the filing path and report-red-main (skipped when recovered, post-merge-demotion-alert.yml:843) have not run.
Has the in-set flake that stays red past the wait been split to its own issue for the --lane-merges-only re-run selector?
RECOMMENDED: Create it as a separate Automation Lanes issue, as the owner's decision says; it is not part of this one. Basis: .github/workflows/pr-merge.yml:173 and the decision comment

Sources read

/home/runner/work/_temp/refine-data/context.json: owner decision keeps this issue only for the live check of the filing path and report-red-main
/home/runner/work/_temp/refine-data/context.json: 2026-10-22 comment shows 7 reds, all recovered, nothing filed, report-red-main skipped
post-merge-demotion-alert.yml:343-347: main_recovered prints 'nothing filed' and sets recovered=true
post-merge-demotion-alert.yml:843: report-red-main runs only when recovered != 'true'

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

Navigation Menu

Repository navigation

chore(pr-pipeline): verify the per-merge red send to the alert after #8897 merges #8898

Check

Open question for the owner

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

chore(pr-pipeline): verify the per-merge red send to the alert after #8897 merges #8898

Description

Check

Open question for the owner

Activity

github-actions commented on Oct 21, 2026

kyle-sexton commented on Oct 22, 2026

kyle-sexton commented on Oct 22, 2026

kyle-sexton commented on Oct 25, 2026

melodic-automation-lanes commented on Oct 25, 2026

melodic-automation-lanes commented on Oct 25, 2026

melodic-automation-lanes commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions