[eslint-refiner] ESLint Refiner daily report - 2026-09-23

[github-actions[bot]]

ESLint Refiner — daily report (2026-09-23)

Overview: disciplined 0-issue run. The day's only open-issue expiry (#61044) turned out to be a genuine upstream fix rather than routine bot housekeeping, and a second, previously-unfiled latent finding was independently confirmed fixed too. One new structural theory was explored across 7 rules sharing a common utility but found zero live grounding, so it was documented rather than filed.

Key metrics

• Rules registered: 62 (unchanged since 2026-09-19)
• Open eslint-factory-labeled issues: 6 (down from 7; #61044 dropped off — confirmed fixed, not just expired)
• Issues created today: 0
• Rules reviewed this run: 5 (2 re-verifications, 1 new cross-rule theory, 2 chronic-gap reconfirmations)

What changed upstream

• prefer-actions-exec-over-child-process (#61044 fixed): the rule now has an explicit requiresShimCjs() early-return that exempts files requiring ./shim.cjs (which only polyfills core/context, never @actions/exec's exec global) — with 2 new dedicated test cases. This directly fixes the dual-mode false-positive flagged back on 2026-09-15.
• require-http-response-error-listener: the addListener-as-alias-for-.on() and req.on("response", cb) chained idiom (flagged 2026-09-09) is also already handled in current source (LISTENER_METHODS includes addListener; getResponseEventCallback walks the chained form). All 4 live call sites in the corpus (handle_agent_failure.cjs:1847, mcp_cli_bridge.cjs:248, start_mcp_gateway.cjs:560, mount_mcp_as_cli.cjs:245) are correctly guarded.

New theory investigated (not filed — zero live grounding)

core-method-resolve.ts multi-hop alias-chain gap — shared by 7 consumer rules: no-core-error-then-process-exit, no-core-error-then-process-exitcode, no-core-error-then-setfailed, no-core-exportvariable-non-string, no-core-setoutput-non-string, no-setfailed-then-exit-zero, require-return-after-core-setfailed.

isCoreAliasIdentifier()'s variable branch resolves exactly one hop of aliasing back to a direct core binding or a JSDoc-annotated DI parameter (e.g. const c = core; or const c = coreArg; both work). A second hop — const a = core; const b = a; b.setFailed(...) — is not recognized, because the intermediate a is a Variable def, not a Parameter, so the JSDoc slow-path check fails.

This is a real structural limitation with a wide blast radius (7 rules), but grepping the full non-test corpus found zero occurrences of even single-hop const x = core;-style aliasing — the codebase either references core directly or uses the JSDoc DI-parameter pattern (7 files) without further re-aliasing. Retained as a documented latent theory in repo-memory; will only be worth filing if a live single-hop alias appears first.

Chronic gaps reconfirmed unchanged (2+ expiries — not refiled, needs a source PR)

• try-catch-rule-utils.ts: SAFE_WRAPPABLE_STATEMENT_TYPES still only covers ExpressionStatement/ReturnStatement, so a VariableDeclaration statement (e.g. const x = fs.readFileSync(...)) gets no wrap-in-try-catch suggestion. Affects ~14 fs-sync/child-process-family rules. Twice filed and expired (#57868/#59891).
• no-json-stringify-equality: still requires both operands of ===/!== to be direct JSON.stringify(...) calls; comparing via an intermediate variable escapes detection. Twice filed and expired (#57869/#59892).

Both require a source-level fix beyond this workflow's create_issue/create_discussion capabilities (no create_pull_request safe-output available) — flagging here for a human or PR-capable workflow to pick up.

Still-open issues (no fresh expiries today)

• #62560 — no-string-fallback-for-non-string-message: alias type-narrowing false positive
• #62317 — require-invalid-date-check-before-compare: arithmetic-derived duration recurrence
• #61543 — require-spawnsync-error-check: CHILD_PROCESS_OBJECTS alias gap
• #61542 — require-fetch-response-body-try-catch: chain-unwrap gap
• #61285 — require-error-code-in-thrown-error: ERROR_CODE_PATTERN vocabulary mismatch
• #61284 — require-error-code-in-thrown-error: nested-alias bypass

Next actions

• Continue the day-over-day open-issues diff as the primary detection method — git-log-based change detection remains unusable (6 consecutive shallow-clone squash-artifact confirmations).
• Before refiling any future expiry, re-read current rule source first: today's #61044 proves an expiry can mean a real fix landed, not just bot housekeeping.
• Revisit the core-method-resolve.ts multi-hop alias theory only if a live single-hop core alias appears in the corpus.
• The two chronic 2+-expiry gaps (try-catch-rule-utils.ts, no-json-stringify-equality) need a source PR from a workflow with write access — this workflow will keep flagging them in reports rather than re-filing a 3rd time.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• api.anthropic.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "api.anthropic.com"

See Network Configuration for more information.

Generated by 🤖 ESLint Refiner · claude · agent · 217.7 AIC · ⌖ 8.39 AIC · ⊞ 6K · ◷

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

[github-actions[bot]]

This discussion has been marked as outdated by ESLint Refiner.

A newer discussion is available at Discussion #63108.