report-failure: a persistent pre-agent failure appends a row to the outage issue on every trigger

[tend-agent]

Problem

report-failure.sh appends one row per failing run to the open tend-outage issue, unconditionally. That is right for a transient outage — a model-API 5xx, an exhausted subscription window — where the row count is a useful measure of how long the stop lasted. It is wrong for a persistent failure, where the same step reddens on every trigger until a human changes the repo, and the issue accumulates rows indefinitely while saying only "The bot failed to process a request."

Three pre-agent steps fail this way, all deterministic on repo or config state rather than on anything transient:

• Validate auth configured — fails whenever the harness credential input is empty (validate-claude-auth.sh, and the inline openai_api_key check in codex/action.yaml). This is what a per-workflow harness: codex trial without OPENAI_API_KEY looks like, or a credential-secret rename: the rest of the repo keeps working while that one workflow reddens on every trigger.
• Run adopter sandbox setup — fails on any error in the adopter's sandbox_setup: (a bad package name, a moved URL), red on every run until the adopter edits their config.
• Security preflight — same shape, but excluded from the reporter in fix(actions): report an outage when the run fails ahead of the agent #857 on a separate argument (reporting would have the bot write to the repo with its PAT right after the security gate refused to let it operate there).

The confusion is bounded by the nightly enricher naming the cause within a day, but until then an adopter reads a growing table of run links with no mention of a missing secret.

Why not more exclusions

The obvious patch is another id: plus another conjunct on the reporter's if:. That does not scale — an enumerated exclusion list silently goes stale as steps are added, renamed, or reordered, and each entry has to re-litigate whether that step's failure is "really" an outage.

Proposed fix

Bound the append itself, in report-failure.sh, where it covers every persistent-failure class at once and needs no per-step knowledge: before commenting on an existing open outage issue, skip if that issue already carries a row for this workflow ($GITHUB_WORKFLOW) within some window. The first failure still files or appends, so nothing is hidden; the 40th consecutive identical one does not add a row.

Sizing the window is the open design question — long enough that a stuck workflow stops repeating, short enough that a genuine multi-day outage still shows its shape.

Relationship to existing issues

• fix(report-failure): dedup outage comments per run across matrix legs #809 is adjacent but does not reach this. It keys on the run id, so it collapses a matrix's legs within one run and still appends once per trigger across runs — exactly the axis a persistent failure repeats on.
• tend-outage issues can't name the cause, and nothing re-runs the trigger they strand #816 covers the outage issue not naming the cause and nothing re-running the stranded trigger. Complementary: that one makes each row more informative, this one stops rows the reader does not need.

Surfaced while reviewing #857, which widens the reporter's gate from the agent step to the whole job and so admits these steps for the first time.

[tend-agent]

#831 is a worked example of exactly this, and it happened under the current gate — so the fix has value whether or not #857 lands. That outage collected 77 rows in one calendar day (2026-08-04, 08:53Z → 23:12Z), from 17 runs across just 2 workflows. The failing step in every sampled run was the agent step itself, so steps.claude.outcome == 'failure' (claude/action.yaml#L611) admitted all of them. The persistent-failure shape isn't new with #857; #857 just adds more step classes that can produce it.

The two axes separate cleanly on that data, which confirms #809 is complementary rather than overlapping:

Dedup key	Rows on #831
today (none)	77
per run (#809)	17
per workflow + trigger + day (this issue)	3

Two things the proposal needs

1. The row has no workflow key to match on. The table columns are When, Run, Trigger (report-failure.sh#L52-L55) — nothing in a row names the workflow, and schedule has no branch in the REF chain, so all 75 review-reviewers rows on #831 render an identical timestamp / run-link / N/A triple. Recovering the workflow from the run URL costs an API call per row. So this needs the row schema to carry the key first — a Workflow column, or a hidden marker in the cell. GITHUB_WORKFLOW is a default Actions variable, available without adding it to the step's env:.

2. Key on (workflow, trigger, day), not $GITHUB_WORKFLOW alone. A bare workflow key silently drops stranded-work pointers for thread workflows: on #831 the two tend-triage rows cite #829 and #830, and a workflow-only key collapses them into one — losing the pointer to #830 entirely. The script's own comment calls REF "the only pointer back to the work the failure stranded" (#L19-L22). Including the trigger costs nothing on the case that motivated this — cron triggers all carry an empty REF, so review-reviewers still collapses to one row per day.

On the window

A UTC calendar day looks like the right size, for three reasons that don't require tuning: the When column already carries the date, so the key needs no new state (just a prefix match); a genuine multi-day outage still shows one row per workflow per day, preserving its shape and duration; and it matches the nightly enricher's cadence, which is already the interval within which a reader gets the real diagnosis. On #831 that's 77 → 3 with no information lost that the reader needed.

Sequencing

Three open PRs currently touch this file — #809, #836, and #857 — and #809 edits the exact if [ -n "$EXISTING" ] branch this guard belongs in, landing the read-body-and-comments-then-grep mechanism this would reuse. I haven't opened a PR for that reason: a fourth parallel change to report-failure.sh would conflict with all three and duplicate #809's matching machinery. This is cleanest as a small extension once #809 merges.

Method

gh api "repos/max-sixty/tend/issues/831/comments?per_page=100" --paginate --jq '.[].body' > c831.txt
grep -E '^\| 20[0-9]{2}-' c831.txt | wc -l                                 # 77 rows
grep -oE 'actions/runs/[0-9]+' c831.txt | sed 's|.*/||' | sort -u | wc -l   # 17 distinct runs
grep -c 'N/A' c831.txt                                                     # 75 rows with no trigger ref

Workflow names resolved per run id with gh api repos/max-sixty/tend/actions/runs/<id> --jq .name: 16 × review-reviewers (5-leg matrix, hourly cron → 6–8 rows per run), 3 × tend-triage. Failing step sampled from .../jobs: Run max-sixty/tend/claude@0.1.13 on every leg.

Grouping the 77 parsed rows by (workflow, trigger cell, date prefix of When) yields 3 groups: review-reviewers / N/A / 2026-08-04, tend-triage / #829 / 2026-08-04, tend-triage / #830 / 2026-08-04.