[Code Quality] Improve 404 error handling in safe output add_comment operations

[github-actions]

Description

The add_comment safe output handler treats HTTP 404 "Not Found" errors as failures when they represent expected race conditions in distributed systems. When a discussion/issue is deleted between agent execution and safe output job execution, the 404 should be logged as a warning rather than causing job failure.

Current Situation

Error Pattern:

##[error]Failed to add comment: Not Found
##[error]✗ Message 1 (add_comment) failed: Not Found

Current Behavior:

• Agent executes and queries discussion #N (exists)
• Agent outputs instruction to add comment to #N
• Discussion #N is deleted (manually or by another workflow)
• Safe output job attempts to add comment → 404 error → job fails

Impact:

• Safe output jobs marked as "failed" for expected conditions
• Noise in monitoring/alerting systems
• Reduced confidence in success rate metrics
• Other successful operations in the same job are overshadowed

Suggested Changes

Modify error classification in the safe output handler to differentiate between:

Critical Errors (fail job):

• 403 Forbidden (permission issues)
• 500 Internal Server Error (API failures)
• Authentication failures
• Unhandled exceptions

Warnings (log but continue):

• 404 Not Found (resource deleted - expected race condition)
• 409 Conflict (resource already exists)
• Rate limit warnings

Implementation Approach

1. Update error handling in actions/setup/js/safe_output_handler_manager.cjs (or equivalent)
2. Add error classification function to distinguish error severity levels
3. Update processing summary to show warnings separately from failures
4. Ensure 404 errors still appear in logs for debugging visibility
5. Update tests to verify 404 handling behavior

Files Affected

• actions/setup/js/safe_output_handler_manager.cjs (error handling logic)
• Related test files for safe output handlers

Success Criteria

• 404 errors are logged as warnings instead of errors
• Safe output job continues processing remaining operations after 404
• Workflow status remains "success" when only 404 errors occur
• 404 errors still visible in job logs for debugging
• Other HTTP errors (403, 500) still treated as failures
• Success rate metrics improve (expected race conditions no longer count as failures)

Testing Scenarios

1. Race Condition Test: Delete target resource between agent and safe output execution → Warning logged, job succeeds
2. Permission Error Test: Use token without write permissions → Error logged, job fails
3. Mixed Operations Test: One 404 + other successful operations → Warning logged, other ops succeed, job succeeds
4. Multiple 404s Test: All operations hit 404 → Warnings logged, job succeeds

Source

Extracted from Safe Output Health Report discussion #11409

Original Finding:

"Agents attempted to add comments to discussion #11400 which no longer exists. The discussion was deleted between agent execution and safe output job execution, creating a race condition. This is an expected race condition in distributed systems, not a system failure."

Affected Runs:

• §21268398422 - Smoke Codex
• §21268398431 - Smoke Copilot

AI generated by Discussion Task Miner - Code Quality Improvement Agent

• expires on Feb 13, 2026, 1:34 AM UTC