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

[github-actions[bot]]

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

One new issue filed today after grounding a fresh gap in no-github-request-interpolated-route's Octokit-client detection; one long-standing chronic theory was retired after its 2nd unfixed expiry.

Key metrics

• Rules tracked: 62 (unchanged since 2026-09-19)
• Issues filed today: 1
• Open eslint-factory issues (post-filing): 5 — no-math-minmax-array-spread: false positive on identifiers holding statically-bounded arrays #63781, require-escaped-regexp-interpolation: no recognition for regex-fragment constants (5 sites already need manual disable, 1 unsupp #63566, require-fetch-response-body-try-catch: chain-unwrap gap hides .catch()/.then()-chained body reads (recurrence of #61542) #63359, no-string-fallback-for-non-string-message: false positive on type-narrowed catch-param alias (recurrence of #60757) #62560, plus today's new filing
• Chronic themes retired today: 1 (#62317 / arithmetic-derived-duration, 2nd expiry)
• HEAD: 5c74985 ([docs] docs: unbloat MCP gateway changelog #64145) — 12th consecutive shallow-clone squash artifact; git-log diffing remains unusable for change detection

New issue: fallback-expression Octokit client aliases bypass detection

no-github-request-interpolated-route resolves the route argument through alias chains fine (that side was fixed via #49913), but its client-detection side (isOctokitSourceExpression/isIdentifierBoundToOctokitClient) only recognizes single-hop direct aliases — const x = github, const x = getOctokit(...), const x = context.github — exactly what its own test suite covers (lines 242–335). A client bound via a fallback expression (x || github, or a ternary) is invisible to the rule, so a .request() call through it gets zero route-safety analysis regardless of how dynamic the route is.

Live grounding detail

• actions/setup/js/update_activation_comment.cjs:206-211 — const fallbackClient = options.targetGithubClient || github; then fallbackClient.request("POST /repos/{owner}/{repo}/issues/{issue_number}/comments", {...}). Today's route is a static literal (no live misfire), but the call site currently receives no analysis at all from this rule.
• actions/setup/js/sub_issue_helpers.cjs:15 — return githubClient || github;, the same fallback-client idiom, confirming it recurs in this codebase (this one only reaches .graphql(), out of the rule's scope, but shows the pattern isn't a one-off).

Proposed fix: extend the Octokit-source check to recurse into LogicalExpression.right and ConditionalExpression.consequent/.alternate, mirroring how the route side already recurses into BinaryExpression for string concatenation.

Retired theme

#62317 (require-invalid-date-check-before-compare arithmetic-derived-duration, recurrence of #60757) expired not_planned on 2026-09-28 — its 2nd expiry without a fix landing. Per the established precedent for repeatedly-expired-but-ungrounded-enough-not-to-refile themes (no-json-stringify-equality #57869/#59892, try-catch-rule-utils.ts #57868/#59891), this is now retired from the refiling rotation; it will only be mentioned in future reports, not reopened a 3rd time.

Watching for next run

• #62560 (no-string-fallback-for-non-string-message alias-FP, recurrence of #60757) is now 7 days old — at the historical ~1-week first-expiry window. If it expires unfixed, that would be its 2nd expiry and it should likewise be retired rather than refiled.
• Confirmed (again) 3 instances where an upstream fix landed without the tracking issue being closed (#61044, #61543, and now effectively this pattern for expired-not-fixed items too) — this workflow only has create_issue/create_discussion/missing_tool/missing_data/noop, no close_issue or PR-authoring capability, so it cannot close stale issues or submit the long-standing try-catch-rule-utils.ts VariableDeclaration-suggestion fix itself. Flagging again for a human or PR-capable workflow to pick up.

Investigated, no issue filed

no-json-stringify-set-or-map's binding resolution (getConstSetOrMapBindingKind) only tracks const VariableDeclarator initializers — a Set/Map returned from a helper function (loadCustomSafeOutputJobTypes, buildAllowedFieldSet, parseAllowedPullRequests, getRecentCollaborators, etc.) or received as a function parameter (e.g. the ~15-file-wide temporaryIdMap idiom) would escape detection if directly JSON.stringify'd. Checked every producer function and every Set/Map-typed JSDoc @param site for an adjacent JSON.stringify call — zero live hits. Real structural gap, but ungrounded; not filed, kept as a candidate for re-scanning if the corpus grows a matching call site.

Next actions

• Re-verify #62560 expiry status at the start of next run.
• Continue the "re-scan previously thin/zero-grounding rules against the current corpus" method — candidates not revisited since 2026-09-11: no-caught-error-interpolation, prefer-structured-clone, require-lastindex-reset-before-global-exec-loop, no-empty-catch-block, require-fs-close-sync.
• No PR-authoring capability in this workflow — the chronic try-catch-rule-utils.ts suggestion gap and the close-issue-on-fix gap both need a human or a differently-scoped workflow.

Generated by 🤖 ESLint Refiner · claude · agent · 248.1 AIC · ⌖ 6.98 AIC · ⊞ 4.8K · ◷

• expires on Sep 29, 2026, 9:34 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-09-30T05:34:46.847Z.

Closed by Workflow