[aw-failures] [aw] Scheduled workflow fails Process Safe Outputs when agent emits update_issue target:triggering

[github-actions]

Problem statement

A scheduled (non-issue-context) agentic workflow fails the safe_outputs / Process Safe Outputs job — and therefore the whole run — when its agent emits an update_issue safe-output whose target resolves to triggering. There is no triggering issue on a schedule run, so the handler logs Target is "triggering" but not running in issue context, skipping update_issue and counts the skipped item as a hard failure (1 message(s) failed to process → step exit non-zero), even though the agent job succeeded and every other emitted item was applied.

Affected workflows and run IDs

1. LintMonster — §27735258410 (main, schedule, 2026-06-18 03:50 UTC). agent job success; safe_outputs / Process Safe Outputs failure.

Evidence

1. The agent emitted two items: update_issue and create_discussion.
2. create_discussion succeeded — discussion #39947 was created (✓ Message 2 (create_discussion) completed successfully).
3. update_issue failed with: ##[error]✗ Message 1 (update_issue) failed: Target is "triggering" but not running in issue context, skipping update_issue, producing Failed: 1 → ##[error]1 safe output(s) failed → the Process Safe Outputs step exits non-zero and the run is marked failure.
4. The handler config for this workflow declares update_issue with title_prefix "[lint-monster] " and no explicit issue target, so the default triggering target is used — which is unsatisfiable on a schedule event.

Probable root cause

1. Workflow-definition mismatch: LintMonster runs on schedule (no triggering issue) but its agent is permitted to / chooses to emit update_issue with the default target: triggering. On every scheduled run that emits such an item the target cannot resolve.
2. Fail-hard-on-skip in the handler: a deliberately-skipped, unsatisfiable item (skipping update_issue) is tallied as a processing failure that fails the entire step, rather than being treated as a soft skip/warning. This is the same fail-hard pattern flagged for asset uploads in [aw-failures] [aw] Phantom asset: upload_assets fails despite agent success (missing staged PNGs) #39885 and for PR/dev-branch safe-outputs in [aw-failures] [aw] Copilot CLI exits 1 with no classified error — chronic Daily Model Inventory failures #39946 (P2 note), but here it occurs on a production main schedule run.

Proposed remediation

1. Treat an update_issue target:triggering emitted outside issue context as a soft skip (warn, do not count toward Failed) so a single unsatisfiable item does not fail an otherwise-successful run — mirroring the fail-soft request in [aw-failures] [aw] Phantom asset: upload_assets fails despite agent success (missing staged PNGs) #39885.
2. Constrain the workflow: on schedule-only triggers, do not advertise update_issue (or require an explicit resolvable target) so the agent cannot emit an item that can never apply. Alternatively, route the report exclusively through create_discussion/create_issue (already used successfully here).
3. Surface a clear agent-facing validation at emission time: reject/flag update_issue target:triggering when the run has no issue context, instead of accepting it and failing in the downstream job.

Success criteria / verification

1. A scheduled LintMonster run that emits only an unsatisfiable update_issue does not fail the Process Safe Outputs step; the skip is reported as a warning.
2. No Process Safe Outputs failures attributable to Target is "triggering" but not running in issue context across schedule workflows over a subsequent 24h window.
3. LintMonster produces its discussion report without a run-level failure conclusion.

Parent report: #39883. Analyzed run: 27735258410.
Related to #39885, #39946.

References: §27735258410

Generated by 🔍 [aw] Failure Investigator (6h) · ◷

• expires on Jun 25, 2026, 12:40 AM UTC-08:00

[pelikhan]

@copilot add a check in the safeoutputs MCP server handler to refuse the target triggering without a issue context so that the agent receives the refusal inlined.

[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 · ◷