[eslint-refiner] ESLint Refiner — daily report 2026-08-02

[github-actions[bot]]

Overview

Repo-memory had gone stale for 25 days (last update 2026-07-08), even though the daily refinement workflow kept running throughout that window. Since this sandbox's git clone is shallow (only 1 commit visible), I reconstructed the missing history from the GitHub Issues API instead of git log, then resumed normal operation: reviewed never-before-reviewed rules and filed 2 new grounded findings.

Key metrics

• Custom rules in eslint-factory: 37 (up from 12 tracked in memory — ~25 rules shipped during the gap)
• Rules reviewed this run: 6 (no-caught-error-interpolation, no-setfailed-then-exit-zero, require-fetch-timeout, require-fetch-try-catch, require-fs-io-try-catch, prefer-get-error-message-over-string)
• New issues filed: 2
• Duplicates avoided: 2 (open eslint-factory: require-escaped-regexp-interpolation flags already-escaped values behind variable assignment or safe literal con [Content truncated due to length] #49281/eslint-factory: require-escaped-regexp-interpolation's isRegexEscapeReplaceCall only recognizes the single canonical global-meta [Content truncated due to length] #49282 on require-escaped-regexp-interpolation, filed 2026-07-31 — not re-filed)
• Rules still awaiting first review: require-rmsync-try-catch, require-execfilesync-try-catch

New findings filed today

1. no-caught-error-interpolation misses EventEmitter-style handlers — the rule recognizes catch clauses and inline .catch/.then rejection params, but not an inline callback passed to .on('error', err => ...). Grounded in a live occurrence: actions/setup/js/mcp_server_core.cjs:1052 (process.stdin.on("error", err => server.debug(\stdin error: ${err}`))`).
2. Coverage gap between no-setfailed-then-exit-zero and no-core-error-then-process-exitcode — core.setFailed(msg); process.exitCode = 0; is invisible to both sibling rules: the first only matches process.exit(0)/process.exit() calls (not an exitCode assignment), and the second requires core.error (not setFailed) as its precondition and treats a setFailed call as a scan-stopping marker. No live occurrence found, but precedented by a prior fix (eslint-factory: require-fs-sync-try-catch treats a catch-less try/finally as protective (soundness gap in isInsideTryBlock) #44219) for an equally rare but real soundness gap.

Rules investigated with no gap found (details)

• require-fetch-timeout (newest rule): signal/AbortSignal detection logic is sound; 3 live call sites are missing timeouts but those are code-fix backlog, not rule bugs.
• require-fetch-try-catch: shares already-hardened try/catch utilities; no gap found.
• require-fs-io-try-catch: shares already-hardened fs-sync method resolver; method-scope exclusions are by design.
• prefer-get-error-message-over-string: rule logic traced as correct, but several live call sites that should already trigger it appear un-flagged in the wild. This can't be confirmed without a live lint run (npm is firewalled in this sandbox) — worth a follow-up check with real tooling to rule out an actual bug.

Next actions

• Review require-rmsync-try-catch and require-execfilesync-try-catch (never reviewed) in the next run.
• Consider verifying prefer-get-error-message-over-string against a real lint execution outside this sandbox.
• README rule documentation coverage has likely fallen further behind (was 2/12 documented at the last full review; now 37 rules exist) — worth a doc pass, not necessarily an issue.
• Repo-memory has been refreshed and pushed this run; going forward it should stay in sync run-to-run.

Generated by 🤖 ESLint Refiner · agent · 215.2 AIC · ⌖ 30.5 AIC · ⊞ 4.9K · ◷

• expires on Aug 2, 2026, 10:33 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-08-03T06:33:09.602Z.

Closed by Workflow