[Code Quality] Fix correctness footgun: core.setFailed() followed by process.exit(0) silently resets exit code to success

[github-actions]

Description

A latent correctness issue exists in workflow JS code: calling core.setFailed(msg) immediately followed by process.exit(0) passes the require-return-after-core-setfailed ESLint rule but overrides the failure exit code to success, defeating the intent of setFailed.

This is a silent correctness bug: the workflow appears to succeed from GitHub Actions perspective even though an error was reported.

Source

Extracted from ESLint Refiner Daily Report 2026-07-22 — Backlog observations section.

Suggested Changes

1. Add an ESLint rule (no-setfailed-then-exit-zero or extend require-return-after-core-setfailed) that detects core.setFailed(...) followed by process.exit(0) and flags it as an error
2. Search and fix any existing occurrences in the codebase: grep -rn "process.exit(0)" pkg/workflow/js/ | grep -B5 "core.setFailed"
3. Add test cases to the rule covering the process.exit(0) override pattern

Files Affected

• pkg/workflow/js/ — eslint-factory rule definitions
• Any .cjs scripts using core.setFailed() near process.exit(0)

Success Criteria

• New or extended lint rule catches core.setFailed() + process.exit(0) pattern
• Zero existing violations after fixing occurrences
• All ESLint rule tests pass

Priority

Medium — silent correctness bug that could cause failed workflows to appear successful.

🔍 Task mining by Discussion Task Miner - Code Quality Improvement Agent · sonnet46 91.8 AIC · ⌖ 8.11 AIC · ⊞ 7.1K · ◷

• expires on Jul 22, 2026, 11:43 PM UTC-08:00