Repository navigation
Skip add_labels when no triggering issue or PR exists - #65619
Conversation
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
✅ PR Code Quality Reviewer completed the code quality review.
|
|
✅ Ponytail Reviewer completed successfully! Lean already. Ship.
|
|
✅ Design Decision Gate 🏗️ completed the design decision gate check. See the comment below for the result and any generated ADR draft. Warning Threat Detection Engine Failure — The analysis engine could not complete. This is a tooling failure, not a security finding. What happenedThe threat detection engine failed to produce results. Review the workflow run logs for details.
|
|
✅ Test Quality Sentinel completed test quality analysis. Test Quality Sentinel skipped because pre-fetch PR data was unavailable: unable to fetch test file diff
|
|
🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅
|
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Hard target-resolution failures are currently ignored, bypassing fail-closed target validation.
Review effort: Balanced
Findings: 1
What changed in this PR
Updates add_labels to skip default triggering targets when no issue or pull request context exists.
Changes:
- Adds soft-skip target resolution.
- Adds handler and manager regression coverage.
| File | Description |
|---|---|
actions/setup/js/add_labels.cjs |
Adds triggering-context resolution and skip handling. |
actions/setup/js/add_labels.test.cjs |
Tests issue, PR, and missing-context behavior. |
actions/setup/js/safe_output_handler_manager.test.cjs |
Verifies skipped labels are nonfatal. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
| const targetResult = resolveTarget({ targetConfig: target, item: message, context, itemType: HANDLER_TYPE, supportsPR: true }); | ||
| if (!targetResult.success && targetResult.shouldFail === false) { | ||
| core.warning(targetResult.error); | ||
| return { success: false, skipped: true, reason: targetResult.error, error: targetResult.error }; | ||
| } | ||
| itemNumber = triggeringItemNumber; |
There was a problem hiding this comment.
Fixed in 45b8bd3: add_labels now returns hard resolveTarget failures and uses its validated issue/PR number, preventing forwarded string-number contexts from reaching the API.
Comment MemoryNote This comment is managed by comment memory.It stores persistent context for this thread in the code block at the top of this comment.
|
There was a problem hiding this comment.
Verdict
No blocking issues found in the changed lines.
Review notes
I checked the new add_labels triggering-context skip path and the added manager regression coverage. The handler now converts the missing issue/PR context into a skipped result instead of a fatal failure, and the manager test covers the exact mixed-success case that motivated the change. I did not find a correctness or maintainability regression in the patched lines that would justify blocking the PR.
🔎 Code quality review by PR Code Quality Reviewer · copilot · gpt54 · 42.1 AIC · ⌖ 7.04 AIC · ⊞ 19.4K
Comment /review to run again
🧪 Test Quality Sentinel Report✅ Test Quality Score: 100/100 — Excellent
📊 Metrics (2 tests)
✅ Test Classification
Verdict
|
There was a problem hiding this comment.
✅ Test Quality Sentinel: 100/100. 0% implementation tests (threshold: 30%). Both new tests enforce design contracts without violations.
🧪 Test quality analysis by Test Quality Sentinel · copilot · haiku45 · 26.4 AIC · ⌖ 9.28 AIC · ⊞ 8.2K
Comment /review to run again
There was a problem hiding this comment.
Skills-Based Review 🧠
Applied /diagnosing-bugs and /codebase-design to this targeted fix for issue #65599 (add_labels hard-failing the safe-outputs job when there's no triggering issue/PR). The core fix is sound and well-tested, but the same root cause is left unfixed in two sibling handlers.
📋 Key Themes & Highlights
Key Themes
- Incomplete bug fix scope:
remove_labels.cjsandreplace_label.cjsshare the exacttarget === "triggering"code path that was just patched inadd_labels.cjs, but they still return a bare{success:false}(noskipped:true) in the no-context case — meaning they'll continue to hard-fail the safe-outputs job via the samepartitionFailureResultspath described in #65599. Their existing tests (remove_labels.test.cjs:389) still assert the old, broken behavior ("No issue/PR number available"withoutskipped), confirming this wasn't addressed. - Minor redundancy:
add_labels.cjsnow callsresolveInvocationContext(context)twice in the same code path (once directly, once insideresolveTarget) — not incorrect, but worth simplifying sinceresolveInvocationContextcan throw on invalidworkflow_dispatch/repository_dispatchrepo overrides.
Positive Highlights
- ✅ Good regression coverage: both the handler-level skip behavior (
add_labels.test.cjs) and the manager-level "skip doesn't fail alongside a success" scenario (safe_output_handler_manager.test.cjs) are tested, directly mirroring the issue's reproduction steps. - ✅ Correctly reuses the existing
resolveTarget/shouldFailconvention already established inupdate_handler_factory.cjs, keeping the skip semantics consistent across handlers rather than inventing a new convention. - ✅ Minimal, surgical diff that doesn't touch unrelated logic.
Requesting changes to extend the same fix to remove_labels.cjs and replace_label.cjs (or extract a shared helper) so the regression class is fully closed rather than fixed for one of three affected handlers.
🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · copilot · sonnet50 · 116.2 AIC · ⌖ 14.7 AIC · ⊞ 10K
Comment /matt to run again
| if (!targetResult.success) return targetResult; | ||
| itemNumber = targetResult.number ?? triggeringItemNumber; | ||
| } else if (target === "triggering") { | ||
| const targetResult = resolveTarget({ targetConfig: target, item: message, context, itemType: HANDLER_TYPE, supportsPR: true }); |
There was a problem hiding this comment.
[/codebase-design] resolveInvocationContext(context) is already called two lines above (line 287) to get triggeringItemNumber, and resolveTarget calls it again internally. Besides the redundant work, resolveInvocationContext can throw (e.g. checkAllowedRepo validation failures for workflow_dispatch/repository_dispatch overrides) — the first call at line 287 is unguarded, so that failure mode predates this PR, but adding a second call site here doubles the chance of an uncaught throw bubbling out of the handler instead of being converted into a clean {success:false} result.
💡 Suggested simplification
Since effectiveContext from line 287 and the context resolveTarget recomputes internally should be equivalent, consider passing the already-resolved effectiveContext/triggeringItemNumber into the skip check directly (e.g. a lighter-weight isTriggeringContextAvailable(effectiveContext, { supportsPR: true }) check) rather than invoking the full resolveTarget resolution path a second time just to read shouldFail.
@copilot please address this.
There was a problem hiding this comment.
Fixed in 45b8bd3: the triggering path now uses resolveTarget's validated number and context directly, removing the duplicate invocation-context resolution. The same skip behavior now covers remove_labels and replace_label.
|
@copilot run pr-finisher skill |
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
🎉 This pull request is included in a new release. Release: |

Safe-output jobs failed after successfully creating an issue or discussion because an incidental
add_labelsresult had no triggering issue or PR to target.add_labelswith the defaulttriggeringtarget and no issue/PR context as skipped. Explicit target errors remain fatal.