[eslint-refiner] ESLint Refiner daily report - 2026-09-08: 2 issues filed (fs resolver reassignment gap, fs-close-sync alias misattribution)

[github-actions[bot]]

ESLint Refiner — daily report

Reviewed the eslint-factory/** custom rule set (61 rules registered in index.ts, up from 12 recorded in stale memory) for false positives, weak diagnostics, and missing edge cases. Filed 2 new issues; found 0 duplicates among what was checked.

Key findings

• Rule inventory drifted: persisted memory was last updated 2026-07-08 tracking only 12 rules; actual count is 61. GitHub issue history is the authoritative source going forward, not the memory snapshot.
• 2 issues filed, both extending an already-accepted defect pattern (eslint-factory: isChildProcessObjectBinding (try-catch-rule-utils.ts) doesn't check for reassignment, unlike sibling resolvers #57624) into sibling code paths that hadn't been checked yet:
  1. isIdentifierBoundToFsModule / resolveFsSyncMethodFromIdentifier in try-catch-rule-utils.ts lack a reassignment guard that the sibling command-initializer-utils.ts resolver already has — affects all 7 createFsSyncMethodResolver consumer rules.
  2. require-fs-close-sync.ts's collectIdentifiers/collectCloseTargetVariables collects non-computed MemberExpression.property and object-literal Property.key names as if they were variable references, which can misattribute which file descriptor a closeSync(handle.fd) call actually closes.
• Both findings are latent (no live-firing example found in actions/setup/js/**/*.cjs), matching the precedent set by the already-accepted eslint-factory: require-fs-sync-try-catch treats a catch-less try/finally as protective (soundness gap in isInsideTryBlock) #44219/eslint-factory: isChildProcessObjectBinding (try-catch-rule-utils.ts) doesn't check for reassignment, unlike sibling resolvers #57624 pattern of filing latent soundness gaps in shared resolver utilities.

Rules reviewed this pass, no defect found

• prefer-get-error-message-over-string.ts — isDefinitionAvailableAtNode, hasResolvableLocalBinding, resolvesToCaughtErrorVariable all correctly scope-walk; judged sound.
• require-fetch-timeout.ts — locally-shadowed fetch (e.g. via node-fetch) bypasses the signal-option check, but no live import of a shadowing fetch exists in actions/setup/js, and the shadow-guard pattern is consistent with other rules' established design. Deprioritized, not filed.
• command-initializer-utils.ts — confirmed as the reference-quality implementation (resolveInitializer's reassignment guard) cited in issue rejig docs #1 above; no new bug.

Issues filed

1. isIdentifierBoundToFsModule in try-catch-rule-utils.ts does not check for reassignment — companion to eslint-factory: isChildProcessObjectBinding (try-catch-rule-utils.ts) doesn't check for reassignment, unlike sibling resolvers #57624, same defect class applied to the fs resolver instead of the child_process resolver. Scope: 7 consumer rules (require-fs-sync-try-catch, require-fs-io-try-catch, require-fs-close-sync, require-mkdirsync-try-catch, require-mkdtempsync-try-catch, require-realpathsync-try-catch, require-rmsync-try-catch).
2. require-fs-close-sync: collectCloseTargetVariables treats property/key names as variable references, can misattribute which descriptor a closeSync(handle.fd) call closes. Existing test suite's only alias test uses shorthand property syntax (key===value name), which masks the bug.

Next actions

• Repo-memory (state.json) rebuilt this run to close the 2-month staleness gap; going forward, GH issue search is treated as authoritative for dedup, not the memory snapshot.
• Still-uninvestigated candidates for a future run: require-realpathsync-try-catch.ts (same resolver family, revisit once the fs-resolver reassignment fix ships), require-fetch-timeout.ts shadow-guard (deprioritized, not clearly a bug).
• Once eslint-factory: isChildProcessObjectBinding (try-catch-rule-utils.ts) doesn't check for reassignment, unlike sibling resolvers #57624 or either issue filed today is fixed, verify: the guard was added to the named function, a regression test was added, and sibling consumer rules' existing suites still pass unchanged.

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 · 394 AIC · ⌖ 7.55 AIC · ⊞ 5.8K · ◷

• expires on Sep 8, 2026, 9:39 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-09-09T05:39:21.748Z.

Closed by Workflow