[eslint-refiner] Daily ESLint Factory Refinement Report — 2026-08-23

[github-actions[bot]]

Overview

First refinement run since 2026-07-08 (a 46-day gap). In that time eslint-factory grew from 12 to 53 custom rules, so 41 rules had never been reviewed. This run reviewed 4 of the unreviewed rules in parallel (via background research agents), grounded findings against the live actions/setup/js/**/*.cjs corpus (no npm/live eslint available — static grep-based verification only), and filed 3 issues.

The standout result: one rule (require-http-response-error-listener) is already correctly flagging a real, unfixed crash bug in production code — it just isn't blocking anything because every one of the 53 custom rules is registered at "warn" severity, not "error".

Key metrics

• Rules in registry: 53 (up from 12 at last run)
• Rules reviewed this run: 4 (require-fs-io-try-catch, no-caught-error-interpolation, require-http-response-error-listener, no-setfailed-then-exit-zero)
• Rules still unreviewed: 37
• Issues filed: 3 (all non-duplicate, dedupe-checked against open issues)
• Rule severity in eslint.config.cjs: 53/53 at "warn", 0 at "error"

Issues filed

1. runtime_import.cjs: unhandled response 'error' listener crashes on socket-level failures — require-http-response-error-listener correctly flags fetchUrlContent (actions/setup/js/runtime_import.cjs:732-757): the .on('error', ...) is attached to the HTTP request object, not the response (res) passed to the callback. Node emits 'error' on the response itself for mid-stream socket failures, so this crashes the action on a dropped connection during a remote @import fetch. Verified as a true positive by re-reading the rule's resolution logic against the exact call site — not a rule bug, a real one the rule already catches. It went unfixed because the diagnostic is a warning, not a CI-blocking error.
2. no-caught-error-interpolation: extend to string-concatenation and single-hop const-alias — the rule only visits TemplateLiteral nodes, so "Error: " + err (identical failure mode to `Error: ${err}`) and const msg = err; \${msg}`` both escape detection. No live occurrence in the corpus (it's 100% compliant today), but neither gap has test coverage, so a future refactor could silently reintroduce the bug class.
3. no-setfailed-then-exit-zero: forward-scan stops at nested block boundary — the rule only scans for a following process.exit(0) within the same statement list as core.setFailed(...). A setFailed nested one block deeper (e.g. inside an if with no return/throw) followed by a sibling exit(0) in the enclosing block is invisible to it. No live occurrence — the codebase is currently disciplined — but it's a real gap in the rule's threat model.

Full findings detail, including rules reviewed with no new gaps

require-fs-io-try-catch — reviewed, no issue filed. Both blind spots assumed going in (destructured/aliased fs bindings, catch-less try{}finally{}) are already correctly handled by the shared try-catch-rule-utils.ts (scope-resolution walk + explicit handler != null check). Live corpus check found zero bare unwrapped sync fs I/O calls and confirmed git_patch_utils.cjs:208-217's try/catch/finally is correctly treated as protected. Only gap: the test suite is missing a catch-less-finally regression case that sibling rules already have — too low-value to file on its own.

require-http-response-error-listener rule mechanics (why the finding above is a true positive, not a rule defect): protocol in runtime_import.cjs resolves via a url.startsWith('https') ? https : http ternary — the rule's ConditionalExpression handling in isHttpModuleExpression resolves this correctly since both branches are require('https')/require('http') bindings. getResponseCallback correctly identifies the res => arrow. hasErrorListener scans all references of res for res.on('error', ...)/res.once('error', ...) — only res.on('data', ...) and res.on('end', ...) exist, so it reports. No eslint-disable present.

no-caught-error-interpolation grounding — grepped all non-test .cjs for bare ${err}/${error}/${e} interpolation, string-concatenation, and alias patterns. Every real catch/.then/.on('error') site (check_workflow_timestamp.cjs:61,67, create_issue.cjs:660,1213, mcp_server_core.cjs:1060, safe_outputs_tools_loader.cjs:288,419) already routes through getErrorMessage(err) or a precomputed errorMessage variable — confirmed true negatives.

no-setfailed-then-exit-zero grounding — 58 files call core.setFailed(; cross-referenced every one against every process.exit(0)/process.exitCode = 0 site. Only render_template.cjs has both, in unrelated branches (setFailed+exit(1) at 151-152 vs. an unrelated exit(0) at 163) — correctly not flagged. A secondary, lower-priority note was folded into the same issue: isProcessExitZero excludes computed member access (process['exit'](0)) while the setFailed detector supports it (core['setFailed'](...)) — an internal asymmetry, ungrounded in live code.

Next actions

• Highest-leverage follow-up: audit all 53 "warn"-severity rules for other live true-positive diagnostics that were correctly flagged but never fixed because nothing gates on them (same pattern as the runtime_import.cjs bug). This is likely higher-value than continuing to hunt for new rule-quality gaps, since the rules already exist and may already be silently catching real bugs.
• Continue working through the 37 still-unreviewed rules (list persisted in repo-memory state.json); prioritize the resource/error-listener and control-flow families next, since they've been the highest-signal categories so far.
• no-exec-interpolated-command already has an open issue (no-exec-interpolated-command: zero coverage for the execApi parameter-alias pattern dominant in git_helpers.cjs and create_pull_ [Content truncated due to length] #53915, found during this run's dedupe check but not filed by us) — worth checking in on independently of this backlog.
• Repo-memory (memory/eslint-refiner branch) updated with the full reviewed-rules list, this run's findings, and refreshed operational notes (the git history for eslint-factory/src/rules was squashed at some point, so "find the newest rule via git log" no longer works as a heuristic — future runs should pick from the unreviewed-rules list directly).

Generated by 🤖 ESLint Refiner · agent · 381.2 AIC · ⌖ 7.71 AIC · ⊞ 5.8K · ◷

• expires on Aug 23, 2026, 9:32 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-08-24T05:32:21.158Z.

Closed by Workflow