Problem
Make dispatch_workflow degrade gracefully instead of failing the entire run — Smoke Copilot's finishing safe-output call (dispatch_workflow → haiku-printer) implicitly targets the run's own trigger ref, and when that ephemeral copilot/* branch is gone by the time the ~15-minute run finishes, the whole job gets marked failure even though the actual task completed successfully.
Affected workflows and runs
.github/workflows/smoke-copilot.md / .lock.yml — and the same exposure exists in smoke-copilot-arm, smoke-copilot-aoai-apikey, smoke-copilot-aoai-entra (same dispatch-workflow: {workflows: [haiku-printer]} config, no explicit ref:).
- §30689984827 —
workflow_dispatch on copilot/ca-cli-version-updates, ran 15.4m (22.5k tokens, 25 requests, error_count: 1), then failed at the finishing safe-output step:
##[error]Failed to dispatch workflow "haiku-printer": No ref found for: refs/heads/copilot/ca-cli-version-updates
##[error]1 safe output(s) failed
Probable root cause
dispatch-workflow in smoke-copilot.md (~line 119-122) has no explicit ref:, so it defaults to dispatching against the triggering branch. For workflow_dispatch runs on short-lived copilot/* branches, that branch can be deleted or renamed (PR merged/closed) before the run finishes and the safe-output fires — turning a successful task run into a hard failure over an unrelated follow-up action.
Evidence: the audit's cohort-matched baseline (§30451982110, same task domain/dispatch mode, conclusion: success) shows the only deltas are posture: write_capable → read_only and run_unsuccessful — i.e. this run did strictly less than a normal successful run and still failed, consistent with the dispatch step being the sole point of failure.
Proposed remediation
- Pin
dispatch-workflow to a stable ref (e.g. the repo default branch) instead of the trigger ref — haiku-printer doesn't need the ephemeral branch's code.
- If a dynamic ref is genuinely required, make a missing-ref dispatch failure non-fatal (log a warning, keep the run's
success conclusion) instead of failing the whole job over an ancillary follow-up dispatch.
Success criteria
A Smoke Copilot run whose trigger branch is deleted mid-run still concludes success (or reports the dispatch failure as a non-fatal warning), and dispatch-workflow no longer defaults to a possibly-deleted trigger ref.
Parent: #49245
Analyzed run: 30689984827 (baseline comparison: 30451982110)
Related to #49245
Generated by 🔍 [aw] Failure Investigator (6h) · agent · 191.1 AIC · ⌖ 25.1 AIC · ⊞ 6.8K · ◷
Generalize the fix — this window shows the "one bad safe-output kills the whole job" flaw isn't limited to the ref-not-found case this issue was opened for.
Confirmed recurrence of the original signature:
| Run |
Time (UTC) |
Signal |
| §30715678987 (Smoke Copilot) |
19:51 |
##[error]Failed to dispatch workflow "haiku-printer": No ref found for: refs/heads/copilot/update-model-pricing-table — identical to this issue's original evidence. |
Two more distinct validation errors, same "hard-fail the whole job" architecture, in the same 12-minute span:
| Run |
Time (UTC) |
Failed safe-output |
Error |
| §30716152552 (Smoke Copilot) |
20:03:53 |
dispatch_workflow |
Failed to dispatch workflow "haiku-printer": Required input 'message' not provided — a config/validation bug distinct from the ref-not-found case, not a race condition. |
| §30716130220 (Smoke Codex) |
20:03:18 |
set_issue_field |
Issue field "Status" not found. Available fields: Visibility, Priority, Impact, Effort, DRI, ... Global Status ... — the workflow requests a field name ("Status") that doesn't exist on the target project; the closest real field is "Global Status". |
Action: widen this issue's remediation from "pin dispatch-workflow's ref" to "make any single safe-output item's validation failure non-fatal to the job" — all three errors above are pre-flight validation failures (bad ref, missing required input, unknown field name) that could be caught and reported as a warning instead of failing the entire safe_outputs job. Each of the two new signatures is single-occurrence this window (P2 in isolation) so no separate ticket was opened for them — but three distinct validation failures hard-failing the same job type in one 6h window is a pattern, not noise.
Success criteria: a dispatch_workflow or set_issue_field call with a bad ref, missing input, or unknown field name logs a warning and lets the rest of the safe-outputs batch (and the job's overall conclusion) succeed.
Filed by the 6h Failure Investigator scan covering 2026-08-01T19:19–2026-08-02T01:19 UTC.
Generated by 🔍 [aw] Failure Investigator (6h) · agent · 142.4 AIC · ⌖ 34 AIC · ⊞ 6.8K · ◷
Problem
Make
dispatch_workflowdegrade gracefully instead of failing the entire run — Smoke Copilot's finishing safe-output call (dispatch_workflow→haiku-printer) implicitly targets the run's own trigger ref, and when that ephemeralcopilot/*branch is gone by the time the ~15-minute run finishes, the whole job gets markedfailureeven though the actual task completed successfully.Affected workflows and runs
.github/workflows/smoke-copilot.md/.lock.yml— and the same exposure exists insmoke-copilot-arm,smoke-copilot-aoai-apikey,smoke-copilot-aoai-entra(samedispatch-workflow: {workflows: [haiku-printer]}config, no explicitref:).workflow_dispatchoncopilot/ca-cli-version-updates, ran 15.4m (22.5k tokens, 25 requests,error_count: 1), then failed at the finishing safe-output step:Probable root cause
dispatch-workflowinsmoke-copilot.md(~line 119-122) has no explicitref:, so it defaults to dispatching against the triggering branch. Forworkflow_dispatchruns on short-livedcopilot/*branches, that branch can be deleted or renamed (PR merged/closed) before the run finishes and the safe-output fires — turning a successful task run into a hard failure over an unrelated follow-up action.Evidence: the audit's cohort-matched baseline (§30451982110, same task domain/dispatch mode,
conclusion: success) shows the only deltas areposture: write_capable → read_onlyandrun_unsuccessful— i.e. this run did strictly less than a normal successful run and still failed, consistent with the dispatch step being the sole point of failure.Proposed remediation
dispatch-workflowto a stable ref (e.g. the repo default branch) instead of the trigger ref —haiku-printerdoesn't need the ephemeral branch's code.successconclusion) instead of failing the whole job over an ancillary follow-up dispatch.Success criteria
A Smoke Copilot run whose trigger branch is deleted mid-run still concludes
success(or reports the dispatch failure as a non-fatal warning), anddispatch-workflowno longer defaults to a possibly-deleted trigger ref.Parent: #49245
Analyzed run: 30689984827 (baseline comparison: 30451982110)
Related to #49245
Generalize the fix — this window shows the "one bad safe-output kills the whole job" flaw isn't limited to the ref-not-found case this issue was opened for.
Confirmed recurrence of the original signature:
##[error]Failed to dispatch workflow "haiku-printer": No ref found for: refs/heads/copilot/update-model-pricing-table— identical to this issue's original evidence.Two more distinct validation errors, same "hard-fail the whole job" architecture, in the same 12-minute span:
dispatch_workflowFailed to dispatch workflow "haiku-printer": Required input 'message' not provided— a config/validation bug distinct from the ref-not-found case, not a race condition.set_issue_fieldIssue field "Status" not found. Available fields: Visibility, Priority, Impact, Effort, DRI, ... Global Status ...— the workflow requests a field name ("Status") that doesn't exist on the target project; the closest real field is "Global Status".Action: widen this issue's remediation from "pin dispatch-workflow's ref" to "make any single safe-output item's validation failure non-fatal to the job" — all three errors above are pre-flight validation failures (bad ref, missing required input, unknown field name) that could be caught and reported as a warning instead of failing the entire
safe_outputsjob. Each of the two new signatures is single-occurrence this window (P2 in isolation) so no separate ticket was opened for them — but three distinct validation failures hard-failing the same job type in one 6h window is a pattern, not noise.Success criteria: a
dispatch_workfloworset_issue_fieldcall with a bad ref, missing input, or unknown field name logs a warning and lets the rest of the safe-outputs batch (and the job's overall conclusion) succeed.Filed by the 6h Failure Investigator scan covering 2026-08-01T19:19–2026-08-02T01:19 UTC.