[aw-failures] [Issue Triage Agent] safe_outputs add_labels fails with `No issue/PR number available` on schedule events

[github-actions]

Problem statement

The Issue Triage Agent workflow fails its safe_outputs job whenever it is invoked by a schedule event. The agent emits add_labels safe-output messages, but the safe-outputs handler rejects them because no issue or PR number is available in the trigger context — schedule events have no associated issue.

Unlike the rate-limit cluster, the agent in this case did not specify per-message issue numbers in the add_labels payload, so the handler defaulted to the trigger's issue.number / pull_request.number — which is empty for schedule.

Affected runs

Run	Started (UTC)	Event	Outcome
§25563171842	2026-05-08 15:08:50	schedule	2× add_labels failed with No issue/PR number available

Evidence

safe_outputs log (job §75040431175)

15:13:10  i️ Rate-limit headroom: 14697/15000 requests remaining (97%)
15:13:10  ##[error]✗ Message 1 (add_labels) failed: No issue/PR number available
15:13:10  ##[error]✗ Message 2 (add_labels) failed: No issue/PR number available
15:13:11  📝 Safe output summaries written to step summary
15:13:11  ##[error]2 safe output(s) failed

Note: rate-limit headroom was healthy (97%) — this is unrelated to the rate-limit cluster.

Probable root cause

One of the following:

1. The Issue Triage Agent prompt instructs the agent to emit add_labels for issues it discovers, but the agent emits messages without an explicit issue_number / pull_request_number field, expecting the handler to infer it.
2. The safe-outputs schema for add_labels in this workflow does not require an explicit issue number, but the handler implementation only resolves it from the trigger event payload — which is missing on schedule.
3. The workflow was originally designed for issue_comment / issues triggers and was later wired to schedule without updating the prompt / schema to require per-message issue numbers.

Proposed remediation

• Short-term: update the Issue Triage Agent prompt to require the agent to include the target issue_number field in every add_labels safe-output message when triggered by schedule.
• Medium-term: in the add_labels safe-outputs handler, fail validation at agent time (so the agent retries with a valid payload) instead of at the post-agent safe_outputs step (where the work is lost). The current behavior wastes an agent run.
• Long-term: clarify the add_labels schema contract — either require explicit issue numbers in all events, or document that the handler will fall back to the trigger context only when present.

Verification / success criteria

• Issue Triage Agent runs on schedule complete with safe_outputs conclusion = success.
• Any future add_labels message without a resolvable target either succeeds (with explicit issue_number) or fails fast inside the agent loop, not in the post-agent push step.

Confidence & unknowns

• Confidence: high on the failure signature (explicit No issue/PR number available error).
• Unknown: whether this is the first occurrence — the auto-generated [aw] Issue Triage Agent failed issue is not present in the open list, so this run may not have triggered the failure-reporter (likely because safe_outputs succeeded enough to be ambiguous, or the workflow does not have report-failure-as-issue enabled).

References

• §25563171842 — failed Issue Triage Agent run
• §25574359989 — this investigation run

Parent: #30961

Generated by [aw] Failure Investigator (6h) · ● 14.6M · ◷

• expires on May 15, 2026, 7:22 PM UTC

---

Scope expansion — bug also affects daily-experiment-report (2026-05-09)

The same add_labels ↔ schedule failure mode is now reproduced on a second workflow, confirming this is a generic safe-outputs handler problem and not specific to Issue Triage Agent.

Run	Workflow	Started (UTC)	Event	Outcome
§25596419525	daily-experiment-report	2026-05-09 08:22:53	schedule	safe_outputs job failed: Message 10 (add_labels) failed: No issue/PR number available

Evidence from the failed safe_outputs step

safe_outputs job log (excerpt)

2026-05-09T08:38:09 ##[error]✗ Message 10 (add_labels) failed: No issue/PR number available
2026-05-09T08:38:09 ✓ Recorded noop message: Daily experiment report for 2026-05-09 complete: 5 experiments analysed across 5 workflows. ... Label experiment:active applied to `#30573`. ...
2026-05-09T08:38:09 Failed: 1
2026-05-09T08:38:09 ##[warning]1 message(s) failed to process
2026-05-09T08:38:09 ##[error]1 safe output(s) failed:

Note: the agent itself succeeded (63 turns, 4.99M tokens), so this is solely a safe-outputs-job regression — the agent's analysis output is published, but the label application is silently lost.

Why this strengthens the originally proposed fix

The original remediation proposes either (1) prompt-side guidance for the agent to include issue_number in every add_labels message, or (2) handler-side validation that fails at agent time so the agent retries.

With two workflows now affected — and presumably more schedule-triggered workflows that emit add_labels — option (2) is clearly the right level. Prompt-side fixes would require touching every workflow that uses add_labels on schedule. Centralising the validation in the safe-outputs handler fixes all current and future occurrences.

Cross-reference

• Parent group: [aw-failures] [aw] Failure Investigator (6h) - Issue Group #30961
• Latest 6h-window analysis (2026-05-09 ~07:11–13:11 UTC): only 2 hard agent failures, this and [aw-failures] Claude workflows hit max-turns burning every turn on Bash permission denials (Step Name Alignment, Design Decision Gate) #31178 recurrence — both already tracked, no new parent report opened.

Generated by [aw] Failure Investigator (6h) · ● 22.1M · ◷

[github-actions]

🍪 Issue Monster selected this for Copilot

I've identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.

If assignment succeeds, the Copilot coding agent will analyze the issue and create a pull request with the fix.

Om nom nom! 🍪

🍪 Om nom nom by Issue Monster · ● 92.9K · ◷