[deep-report] Safe-outputs job hard-fails despite the sole configured item succeeding (PR Triage Agent, Auto-Triage Issues) #65599

Description

Two safe-output jobs today reported a hard job failure even though their single configured item was created successfully with a real URL:

• PR Triage Agent (run 37168157408): create_issue succeeded — issue [PR Triage Report] PR triage report - 2026-10-04 #65453 exists with full content — but the safe_outputs job's "Process Safe Outputs" step conclusion is failure.
• Auto-Triage Issues (run 37168204963): create_discussion succeeded — discussion [Auto-Triage] Auto-Triage Issues Report #65451 exists — but the same step hard-failed.

This generalizes a pattern first flagged 2026-09-10 for approve_workflow_run (PR Sous Chef) and push_to_pull_request_branch (Design Decision Gate), where a policy decline was miscategorized as a hard failure. Here there is no policy decline — the write genuinely succeeded — so the existing reclassify-protected-file-decline-as-non-failure fix does not cover this variant. It's now observed on 4 workflows with no fix in 3+ weeks.

Likely code path

actions/setup/js/safe_output_handler_manager.cjs computes fatalFailures (line ~757) from processingResult.results, and if any entry lands in fatalFailures it sets failedOutputsMessage (line ~1910) which triggers core.setFailed(...) (line ~2015) for the whole step — independent of whether the primary configured item (the single create_issue/create_discussion message) itself succeeded. The two runs above suggest some other message/result in the same run (e.g. a secondary handler invocation, a close_older_issues/ledger side-effect, or a mis-classified result) is being counted as a fatal failure alongside — or instead of — the real item.

Suggested investigation

1. Pull the safe-output-items.jsonl / safe-output-errors.json artifacts for runs 37168157408 and 37168204963 (uploaded by the "Upload Safe Outputs Items" step) and inspect processingResult.results to find which entry was classified as a fatal failure.
2. Add a regression test in safe_output_handler_manager.test.cjs that reproduces a single-item run where the configured item succeeds, asserting the step does not fail.
3. If the root cause is a secondary/incidental result (not the user-configured item) being miscounted, exclude it from fatalFailures or report it as a warning rather than a job failure.

Data source

DeepReport analysis of Safe Output Health Report #65507 (2026-10-04), Cluster 2 finding.

Suggested Agent: New Agent or whoever owns safe_output_handler_manager.cjs
Estimated Effort: Medium (1-4 hours) — investigation plus regression test

Generated by 🔬 Deep Report · claude · agent · 310.1 AIC · ⌖ 9.15 AIC · ⊞ 7.1K · ◷

• expires on Oct 6, 2026, 6:22 AM UTC-08:00