Description
actions/setup/js/safe_output_helpers.cjs's shared resolveTarget() correctly signals a soft skip (shouldFail: false) when target: "triggering" is used outside its expected context (e.g. set_issue_type on a PR-comment-triggered run with no issue context). Most callers respect that flag and convert it into a skipped: true result so safe_output_handler_manager.cjs treats it as a benign skip — see add_labels.cjs:299-301 (if (targetResult.shouldFail === false) { ... }) and create_check_run.cjs:120-137 (skipped: !targetResult.shouldFail).
Two handlers drop the flag instead of checking it, so the handler manager's generic result.success === false check (safe_output_handler_manager.cjs:1105) treats the no-context case as a hard failure, failing the entire safe_outputs job:
actions/setup/js/set_issue_type.cjs:246 — if (!targetResult.success) return { success: false, error: targetResult.error }; discards targetResult.shouldFail entirely.
actions/setup/js/submit_pr_review.cjs:184-187 (handleWithRegistry) — same pattern: return { success: false, error: errMsg }; with no shouldFail/skipped propagation. (Note: the other resolveTarget call in the same file, lines 251-274, already handles this correctly by only warning when shouldFail is true — so the fix pattern already exists side-by-side in the same file.)
This was surfaced by the Safe Output Health Report — 2026-10-06, which observed set_issue_type hard-failing on a PR-comment-triggered run (Smoke Copilot, PR #65937, run 37375351430) with error Target is "triggering" but not running in issue context, skipping set_issue_type — the message itself says "skipping" but the job fails anyway. The report traced this to a shared design inconsistency but could not pinpoint the exact file from logs alone; this issue identifies the two exact call sites.
Expected Impact
Fixes a real safe-output job failure (not just a metrics artifact) for any workflow that uses set_issue_type or submit_pull_request_review with the default target: "triggering" when triggered from a context lacking the required issue/PR (confirmed across 2 workflows over 5+ weeks per the source report). Also removes noise from safe-output success-rate monitoring.
Suggested Agent
Code Scanning Fixer or a general bug-fix agent — mechanical, same fix pattern already present in both files.
Estimated Effort
Quick (< 1 hour) — mirror the existing correct pattern (targetResult.shouldFail === false → return { success: true, skipped: true, reason: targetResult.error } or equivalent) at the two identified call sites, add a regression test asserting a soft skip (not job failure) when shouldFail is false.
Data Source
DeepReport Intelligence Briefing (cycle 6), 2026-10-06. Source: Safe Output Health Report - 2026-10-06 (#66015), root-caused to exact file/line via direct source read this cycle.
Generated by 🔬 Deep Report · claude · agent · 353.2 AIC · ⌖ 8.63 AIC · ⊞ 7.1K · ◷
Description
actions/setup/js/safe_output_helpers.cjs's sharedresolveTarget()correctly signals a soft skip (shouldFail: false) whentarget: "triggering"is used outside its expected context (e.g.set_issue_typeon a PR-comment-triggered run with no issue context). Most callers respect that flag and convert it into askipped: trueresult sosafe_output_handler_manager.cjstreats it as a benign skip — seeadd_labels.cjs:299-301(if (targetResult.shouldFail === false) { ... }) andcreate_check_run.cjs:120-137(skipped: !targetResult.shouldFail).Two handlers drop the flag instead of checking it, so the handler manager's generic
result.success === falsecheck (safe_output_handler_manager.cjs:1105) treats the no-context case as a hard failure, failing the entiresafe_outputsjob:actions/setup/js/set_issue_type.cjs:246—if (!targetResult.success) return { success: false, error: targetResult.error };discardstargetResult.shouldFailentirely.actions/setup/js/submit_pr_review.cjs:184-187(handleWithRegistry) — same pattern:return { success: false, error: errMsg };with noshouldFail/skippedpropagation. (Note: the otherresolveTargetcall in the same file, lines 251-274, already handles this correctly by only warning whenshouldFailis true — so the fix pattern already exists side-by-side in the same file.)This was surfaced by the Safe Output Health Report — 2026-10-06, which observed
set_issue_typehard-failing on a PR-comment-triggered run (Smoke Copilot, PR #65937, run 37375351430) with errorTarget is "triggering" but not running in issue context, skipping set_issue_type— the message itself says "skipping" but the job fails anyway. The report traced this to a shared design inconsistency but could not pinpoint the exact file from logs alone; this issue identifies the two exact call sites.Expected Impact
Fixes a real safe-output job failure (not just a metrics artifact) for any workflow that uses
set_issue_typeorsubmit_pull_request_reviewwith the defaulttarget: "triggering"when triggered from a context lacking the required issue/PR (confirmed across 2 workflows over 5+ weeks per the source report). Also removes noise from safe-output success-rate monitoring.Suggested Agent
Code Scanning Fixer or a general bug-fix agent — mechanical, same fix pattern already present in both files.
Estimated Effort
Quick (< 1 hour) — mirror the existing correct pattern (
targetResult.shouldFail === false→ return{ success: true, skipped: true, reason: targetResult.error }or equivalent) at the two identified call sites, add a regression test asserting a soft skip (not job failure) whenshouldFailis false.Data Source
DeepReport Intelligence Briefing (cycle 6), 2026-10-06. Source: Safe Output Health Report - 2026-10-06 (#66015), root-caused to exact file/line via direct source read this cycle.