[eslint-refiner] ESLint Refiner daily report — 2026-09-16

[github-actions[bot]]

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

Scope this run: require-error-code-in-thrown-error (top carried-over priority from 2026-09-15, first-ever grounding of this rule), plus a lighter secondary pass on require-fetch-try-catch.

Key metrics

• 62 custom rules registered in eslint-factory (unchanged since 2026-09-10)
• 2 new issues filed this run, both on require-error-code-in-thrown-error
• 7 rules with previously-filed issues still open going into this run (per gh api ...labels=eslint-factory); 2 more expired/closed silently since yesterday (#59378, #59377, require-fs-close-sync)
• ~23 / 62 rules still never reviewed by this refinement loop

Issues filed

1. Nested identifier aliases bypass write-once resolution inside binary/template messages — messageReferencesErrorCode resolves a top-level Identifier message (e.g. const msg = ERR_API + ...; throw new Error(msg)) via resolveWriteOnceInitializerChain, but when that same alias appears nested inside a + concatenation or a template-literal interpolation (throw new Error(prefix + ": failed"), throw new Error(`${prefix}: failed`)), the rule only checks the identifier's bare name and misses the resolution — a false missingErrorCode. Latent (no live misfire found across 128 importing files today), but the idiom is ordinary and the blast radius is rule-mechanism-wide.
2. ERROR_CODE_PATTERN doesn't recognize error_codes.cjs's own non-ERR_*/E0xx exports — the module the rule cites as its source of truth also exports CONFIG_HASH_MISMATCH, RATE_LIMIT_EXCEEDED, and POLICY_FILE_PROTECTION_DENIED_REASON_CODE, none of which match the rule's recognition regex. Currently these are only used with core.setFailed() / returned objects, never as the sole code in a thrown Error, so there's no live misfire — but the mismatch is demonstrable directly from error_codes.cjs's own export list.

Full analysis and repro traces

require-error-code-in-thrown-error (eslint-factory/src/rules/require-error-code-in-thrown-error.ts) had never been grounded against the live corpus before — 128 of actions/setup/js's files import error_codes.cjs, too many to review file-by-file, so this run audited the rule's own helper functions for internal asymmetries first, then grepped the corpus for the specific shapes those asymmetries predict.

Finding 1 trace: for const prefix = ERR_API; throw new Error(prefix + ": failed");, the throw argument is a top-level BinaryExpression. auditMessageExpression calls messageReferencesErrorCode(node) first, which recurses into left (Identifier "prefix") and right (string literal), testing each by bare name — "prefix" fails the ERROR_CODE_PATTERN regex, and the literal has no ERR_ text. Since the overall node type is BinaryExpression (not CallExpression or Identifier), auditMessageExpression falls through to return "missingCode" — even though prefix provably resolves to ERR_API one hop away. The same root cause reproduces for a template-literal interpolation (`${prefix}: failed`) and for a helper function whose single return statement has this shape. A search across actions/setup/js/*.cjs for = fetch(/throw new Error(<ident> +-style aliasing found zero live occurrences today — this is a latent gap, not a currently-misfiring diagnostic, but "assign a code to a local const before concatenating" is a completely ordinary refactor with nothing in the codebase discouraging it.

Finding 2 trace: error_codes.cjs:61-72,87-89 exports CONFIG_HASH_MISMATCH = "CONFIG_HASH_MISMATCH", RATE_LIMIT_EXCEEDED = "RATE_LIMIT_EXCEEDED", and POLICY_FILE_PROTECTION_DENIED_REASON_CODE = "POLICY_FILE_PROTECTION_DENIED" alongside the ERR_*/SAFE_OUTPUT_E0xx constants. None of the three contain ERR_ or a 3-digit E code, so ERROR_CODE_PATTERN.test(...) is false for all of them. Today they're only consumed via core.setFailed(...) (check_workflow_timestamp_api.cjs:426,453) or embedded in returned/thrown-adjacent objects (push_to_pull_request_branch.cjs:529,1123, approve_workflow_run.cjs:372, error_recovery.cjs:262-263) — never as the sole code inside a thrown Error, so there's no live false positive yet, but the rule's own stated scope ("ERR_* from error_codes.cjs") is narrower than what that module actually exports.

require-fetch-try-catch (never previously reviewed) got a lighter secondary pass: two plausible gaps were investigated — (a) isInsideTryBlock's "inline callback directly awaited" exception only unwraps one level of indirection, so await Promise.all(items.map(async item => { await fetch(item.url); })) inside an outer try would likely still be misflagged even though the rejection legitimately propagates to the outer catch; (b) getAwaitedFetchInfo only recognizes a fetch call as the immediate argument of AwaitExpression, so const p = fetch(url); await p; escapes detection entirely. Neither pattern was found live in actions/setup/js today, so neither was filed — left as a note in repo-memory for a future joint pass across the fetch-family rules (require-fetch-try-catch, require-fetch-timeout, require-fetch-response-body-try-catch), which likely share the same traversal shape.

Next actions

• Continue require-fetch-try-catch / fetch-family joint review (require-fetch-timeout, require-fetch-response-body-try-catch) for the Promise.all/alias gaps noted above, only if new live call sites appear.
• ~23 of 62 rules remain unreviewed by this loop; next candidates queued: require-mkdirsync-try-catch, require-rmsync-try-catch, require-spawnsync-error-check, require-fs-io-try-catch, require-fetch-timeout, require-fetch-response-body-try-catch.
• Re-verify open-issue snapshot each run before citing "already filed, skip" — issues have been observed expiring within ~1 day recently (faster than the previously assumed ~1 week TTL).

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 · 318.3 AIC · ⌖ 7.46 AIC · ⊞ 5.8K · ◷

• expires on Sep 16, 2026, 9:36 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by ESLint Refiner.

A newer discussion is available at Discussion #61544.