[safe-output-health] Safe Output Health Report — 2026-05-27 #35137
Closed
Replies: 1 comment
-
|
This discussion was automatically closed because it expired on 2026-05-28T05:56:59.658Z.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Executive Summary
review_path_unresolved_422REGRESSION — body-only fallback predicate matches only "Line could not be resolved", not today's "Path could not be resolved" variant. Three messages failed hard on §26491875017 (Smoke Copilot).The three-day clean streak (2026-05-23 / 24 / 26) ended today with three independent safe-output failures. The most consequential is a partial regression of the previously-validated
review_path_unresolved_422remediation — the soft-recovery branch fires only on one of the two possible 422 error-message variants. Two of today's failures share a root-cause family with clustertarget_star_review_comment_no_pr_number_fallback(2026-05-22), now exhibited on theadd_commenthandler.Safe-Output Job Statistics
Critical Issue (Always Visible)
🚨 Cluster
review_path_unresolved_422— Body-only fallback predicate too narrowUnprocessable Entity: "Path could not be resolved and Path could not be resolved"actions/setup/js/pr_review_buffer.cjs:554— predicate iserrorMessage.includes("Line could not be resolved") && comments.length > 0. GitHub's review API returns both"Line could not be resolved"and"Path could not be resolved". Today's was the Path variant; the fallback retry block at lines 555–583 was never entered.pr_review_buffer.test.cjs:785covers the Line variant; a mirror test for the Path variant should be added to lock in the dual match.Why the existing pre-validation (Sub-pattern B) didn't catch it
pr_review_buffer.cjs:324validates comment paths againstpulls.listFilesbefore submission and drops invalid paths. Today's two buffered comments survived pre-validation (one onpkg/constants/version_constants.go:111), so the paths were in the diff listing — but GitHub still rejected them at submit time with "Path could not be resolved". This indicates the API rejects reviews when the resolved position is non-reviewable (e.g. binary diff, renamed/generated file, line outside the hunk range) even whenlistFilesreports the path. Hence the body-only retry remains the correct safety net; the predicate just needs to match both error variants.Error Clusters This Audit
Cluster 1 — review_path_unresolved_422 (regression, see Critical above)
Cluster 2 — target_star_add_comment_no_item_number_fallback (new)
add_commenthandler does not resolve a fallback target the wayupdate_pull_request/submit_pull_request_reviewdo. For schedule-triggered runs there is no triggering issue/PR (so a true fallback is impossible), but the error message should steer the agent towardcreate_issuefor periodic reports, or require an explicititem_number.target_star_review_comment_no_pr_number_fallback(2026-05-22)Cluster 3 — push_to_pull_request_branch size-limit enforcement
Incremental diff size (6100 KB) exceeds maximum allowed size (1024 KB). Bundle size: 1 KB.Soft Recoveries (working as designed)
2 occurrences of approve-on-own-PR → event=COMMENT fallback
Cannot submit APPROVE review on own PR. Retrying with event=COMMENT.→ review #4369550373 created.Recommendations
Critical (Immediate)
pr_review_buffer.cjs:554to match both 422 error-message variants"Line could not be resolved"; misses"Path could not be resolved"pr_review_buffer.test.cjsHigh
add_commenthandler (and tighten error message)actions/setup/js/safe_output_handler_manager.cjs—add_commenthandlertarget: "*"and noitem_numberis provided, fall back to triggering issue/PR fromGITHUB_REF/GITHUB_EVENT(same asupdate_pull_request). For schedule-triggered contexts (no triggering issue/PR), upgrade the error to suggestcreate_issueor an explicititem_number.add_commentwithtarget: "*")Medium
Work Item Plans
Work Item 1 — Fix
review_path_unresolved_422body-only fallback predicatepr_review_buffer.cjs:554matches only one of GitHub's two 422 error-message variants for unresolvable review comments. Today's §26491875017 regressed three messages because the "Path could not be resolved" variant slipped past the predicate.pr_review_buffer.cjs:554predicate matches"Path could not be resolved"in addition to"Line could not be resolved"pr_review_buffer.test.cjsexercises the Path variant and asserts body-only retry + successpr_review_buffer.test.cjs:785)||insertion in the existing condition; mirror existing test case substituting the error messageWork Item 2 —
add_commenttarget="*" fallback to triggering context (or clearer error)add_commenthandler does not fall back to the triggering issue/PR whentarget: "*"and noitem_numberis provided, unlike sibling handlers. For schedule-triggered runs there is no triggering target, but the error message should redirect the agent rather than leaving it stuck.add_commenthandler resolvestarget: "*"to that PR/issue automaticallyschedule/workflow_dispatch, error message explicitly suggestscreate_issueor an explicititem_numberupdate_pull_request/submit_pull_request_reviewhandlersWork Item 3 — Investigate Smoke Claude oversized patch
Historical Context
Trends
add_comment).review_path_unresolved_422now at 4 occurrences with one regression — the remediation needs widening.Metrics & KPIs
submit_pull_request_review+create_pull_request_review_commentrollback) — 3 of 5 failed messagesNext Steps
target_star_add_comment_no_item_number_fallbackdoes not silently recur in other schedule-triggered workflowscancellation_counter_mislabeled_code_push_failed— not exercised today; remediation still pendingReferences:
Beta Was this translation helpful? Give feedback.
All reactions