Safe Output Health Report - 2026-03-30

[github-actions[bot]]

Executive Summary

• Period: 2026-03-29T06:00 → 2026-03-30T06:00 (last 24h)
• Runs Analyzed: 127
• Workflows with Safe Outputs: 43
• Total Safe Output Messages Processed: 84
• Successful: 79 ✅
• Failed: 5 ❌ (in 3 runs)
• Overall Success Rate: 94.0%
• Error Clusters Identified: 2

All failures were low-to-medium severity. No critical failures. Two recurring pattern types identified.

---

Safe Output Job Statistics

Job Type	Executions	Failures	Success Rate
add_comment	30	0	100%
create_discussion	14	0	100%
create_issue	8	0	100%
create_pull_request	7	0	100%
update_issue	7	3	57%
noop	5	0	100%
add_labels	3	2	33%
submit_pull_request_review	2	0	100%
create_pull_request_review_comment	2	0	100%
add_reviewer	1	0	100%
dispatch_workflow	1	0	100%
post_slack_message	1	0	100%
set_issue_type	1	0	100%
update_pull_request	1	0	100%
update_release	1	0	100%

---

Error Clusters

Cluster 1: add_labels — No issue/PR number available

• Count: 2 failures across 2 runs
• Affected Workflows: Contribution Check (§23737169478), Smoke Claude (§23744944648)
• Error:

  ##[warning]No issue/PR number available
  ##[error]✗ Message N (add_labels) failed: No issue/PR number available
  ```
  

• Root Cause: The agent calls add_labels after create_issue, but:
  • In the Contribution Check run: create_issue used group_by_day mode and found an existing issue for the day — it posted the content as a comment to issue [Contribution Check Report] Contribution Check — 2026-03-30 #23502 rather than creating a new issue. No new issue number was registered, so the subsequent add_labels had no target.
  • In the Smoke Claude run: create_issue successfully created issue Smoke Test: Claude - 23744944648 #23546, but add_labels still failed with "no issue/PR number available." The temporary ID aw_6GYZbdqq was registered to Smoke Test: Claude - 23744944648 #23546 but add_labels did not reference it.
• Impact: Labels not applied to the intended issue. Low severity — issue content was still posted successfully.

Cluster 2: update_issue — Not running in issue context

• Count: 3 failures in 1 run
• Affected Workflows: Workflow Health Manager - Meta-Orchestrator (§23743866195)
• Error:

  ##[warning]Target is "triggering" but not running in issue context, skipping update_issue
  ##[error]✗ Message N (update_issue) failed: Target is "triggering" but not running in issue context
  

• Root Cause: The agent called update_issue with target="triggering" three times, but the workflow ran in a non-issue context (scheduled or workflow_dispatch event). The workflow has update_issue configured with target: triggering in GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG, and the agent used it accordingly — but the triggering event was not an issue.
• Impact: Issue updates not applied. Medium severity — the agent's intent was to update issues it found/created in the same run, but all 3 update_issue calls failed.

Cluster 2 — Full Details

Handler config:

{"update_issue":{"allow_body":true,"max":5}}

All 3 update_issue messages had target="triggering" but the run had no triggering issue. The 4 add_comment calls in the same run used explicit item_number fields (#23447, #23193, #23447 again, #23447 third time) and all succeeded. The agent properly used explicit issue numbers for comments but relied on implicit triggering context for update_issue.

---

Root Cause Analysis

Dependent Context Missing (add_labels)

When create_issue uses group_by_day: true or close_older_issues dedup logic, it may not create a new issue — instead posting a comment to an existing one. In this case, no new issue number is exported to the context. A subsequent add_labels tool call with no explicit issue_number or temporary_id reference has nothing to target and fails.

Additionally, even when create_issue does create a new issue (Smoke Claude case), if add_labels doesn't reference the temporary ID that was registered, it may not pick up the new issue number automatically.

Invalid Event Context (update_issue / add_comment)

This is a recurring pattern (also seen 2026-03-29 with add_comment in the same Workflow Health Manager). The agent uses update_issue with target="triggering" in a workflow that can be triggered by schedule or dispatch events. The agent should use explicit issue_number fields or guard against non-issue contexts.

---

Recommendations

Immediate Actions

1. add_labels cross-reference fix — Medium Priority

   • When an agent calls add_labels after create_issue, it should pass the temporary_id used in create_issue as the issue_number target (e.g., "issue_number": "aw_6GYZbdqq"). The safe outputs framework supports temporary ID resolution.
   • Alternatively, the add_labels handler should auto-inherit the last created issue number when no explicit target is provided and a create_issue message was processed earlier in the same run.

2. Workflow Health Manager update_issue fix — Medium Priority

   • The agent should use explicit issue_number fields when calling update_issue instead of relying on target="triggering".
   • This is the same workflow that had add_comment context failures on 2026-03-29 — the pattern is recurring.

Bug Fix Candidates

1. add_labels should inherit created issue number

   • Problem: add_labels with no issue_number fails when called after create_issue in group_by_day or dedup modes that don't create a new issue.
   • Fix Option A: Handler inherits last-exported created_issue_number from earlier in the same run when no explicit target provided.
   • Fix Option B: Agent prompt guidance to always use temporary_id reference in add_labels after create_issue.
   • Affected Jobs: add_labels

2. update_issue context guard

   • Problem: Agent calls update_issue with target="triggering" on workflows triggered without an issue context.
   • Fix: Add workflow-level context awareness — if update_issue with target="triggering" is used, fail gracefully (already does) OR add agent guidance to always use explicit issue numbers in workflows that can run on non-issue events.
   • Affected Jobs: update_issue

Process Improvements

1. Agent prompting for add_labels after create_issue: Docs/examples should show that add_labels requires an explicit issue_number or temporary_id — it does not auto-inherit from a preceding create_issue.

2. Recurring context issue in Workflow Health Manager: This workflow has now produced context-target failures on consecutive days (2026-03-29 with add_comment, 2026-03-30 with update_issue). The agent prompt for this workflow should be updated to use explicit issue numbers for all output operations.

---

Work Item Plans

Work Item 1: Fix add_labels to support temporary_id resolution

• Type: Bug Fix
• Priority: Medium
• Description: add_labels fails with "No issue/PR number available" when called after create_issue in dedup/group_by_day mode because no new issue was created. The safe outputs framework supports temporary ID cross-referencing in other handlers — extend add_labels to resolve temporary IDs as issue numbers.
• Acceptance Criteria:
  • add_labels with issue_number: "aw_XXXX" resolves the temporary ID to the real issue number
  • add_labels after create_issue in same run picks up the created issue number when no explicit target provided
  • Test covers group_by_day dedup case where create_issue posts as comment
• Technical Approach: Mirror the temporary ID resolution logic from add_comment handler into add_labels. Additionally, consider auto-inheriting created_issue_number export when no explicit target is set.
• Estimated Effort: Small
• Dependencies: Temporary ID registry in safe-output framework

Work Item 2: Recurring Workflow Health Manager output context failures

• Type: Investigation + Fix
• Priority: Medium
• Description: The Workflow Health Manager has produced "target is triggering but not running in issue/PR context" errors on 2026-03-29 (add_comment) and 2026-03-30 (update_issue, 3 times). The agent is using context-dependent targets in a workflow that runs on schedule/dispatch.
• Acceptance Criteria:
  • No more "triggering context" failures from Workflow Health Manager
  • Agent uses explicit issue numbers for all update_issue / add_comment calls
  • Workflow prompt updated to guide agent on explicit number usage
• Technical Approach: Update the Workflow Health Manager agent prompt to instruct using explicit issue_number for update_issue and add_comment calls. Optionally fail-safe: when update_issue with target="triggering" is called without issue context, silently skip rather than error.
• Estimated Effort: Small
• Dependencies: Workflow Health Manager prompt

---

Historical Context

Date	Runs	Safe Output Messages	Failures	Success Rate
2026-03-29	42	~66	4	~93.9%
2026-03-30	127	84	5	94.0%

Trends:

• Success rate is stable (~94%). Volume increased significantly (42 → 127 runs, 66 → 84 safe output messages).
• Recurring: invalid_event_context (target="triggering" without issue context) appeared 2 days in a row, in the same workflow (Workflow Health Manager). Pattern is escalating: 1 failure yesterday → 3 failures today.
• New pattern: add_labels "no issue/PR number" appeared for the first time (2 occurrences, 2 workflows).
• Resolved from yesterday: protected-files-pr-block and upload-assets-missing-action-setup not seen today.

Metrics and KPIs

• Overall Safe Output Success Rate: 94.0%
• Most Reliable Job Types: add_comment (100%), create_discussion (100%), create_issue (100%), create_pull_request (100%)
• Most Problematic Job Types: add_labels (33%), update_issue (57%)
• Runs with 0 Messages (no-op agent): 1 (daily-choice-test)

Next Steps

• Fix add_labels handler to support temporary ID resolution and/or inherit created_issue_number
• Update Workflow Health Manager agent prompt to use explicit issue numbers for update_issue / add_comment
• Monitor Workflow Health Manager for recurrence — if it appears again, escalate to High priority
• Verify Smoke Claude's add_labels call uses a temporary_id reference after fix

References:

• §23737169478 — Contribution Check (add_labels failure)
• §23743866195 — Workflow Health Manager (update_issue x3 failure)
• §23744944648 — Smoke Claude (add_labels failure)

AI generated by Safe Output Health Monitor · history

• expires on Mar 31, 2026, 1:21 PM UTC

[github-actions[bot]]

This discussion has been marked as outdated by Safe Output Health Monitor.

A newer discussion is available at Discussion #23723.