[eslint-refiner] ESLint Refiner Daily Report — 2026-09-26

[github-actions[bot]]

Overview

Daily refinement pass over the 62 registered gh-aw-custom ESLint rules in eslint-factory, grounded against the live corpus in actions/setup/js/**. Today's angle: cross-referenced all 62 rule names against the full run history and found require-escaped-regexp-interpolation had never been reviewed — a first audit surfaced a real, broadly-applicable gap with 5 of 6 live occurrences already needing manual eslint-disable-next-line workarounds.

Key metrics

• Rules registered: 62 (unchanged since 2026-09-19)
• Open eslint-factory issues (pre-run snapshot): 3 — #63359, #62560, #62317
• Issues filed today: 1 — require-escaped-regexp-interpolation regex-fragment-constant recognition gap
• HEAD: 8f0d376 ([docs] docs: unbloat GitHub Actions primer #63530) — 9th consecutive all-insertions shallow-clone squash artifact; git-log-based change detection remains unusable in this repo

Today's finding: require-escaped-regexp-interpolation

This rule requires values interpolated into a new RegExp() template literal to be passed through a regex-escaping helper first (guards against unintended matches / ReDoS with attacker-controlled input). It correctly recognizes escape-helper calls, the canonical .replace(/[.*+?^${}()|[\]\\]/g, "\\$&") form, escaped-prefixed names, and safe literal constants — but has no path to recognize a deliberately-authored regex-fragment constant (a const whose value is itself valid regex syntax, e.g. a character class meant to be composed into a larger pattern).

Live grounding detail

File:Line	Interpolated identifier	Suppressed today?
sanitize_content_core.cjs:305	URL_AUTHORITY_CHAR	yes (manual disable comment)
sanitize_content_core.cjs:338	URL_START_DELIMITERS	yes (manual disable comment)
sanitize_content_core.cjs:541	URL_START_DELIMITERS	yes (manual disable comment)
sanitize_content_core.cjs:691	fc, fenceLen	yes (manual disable comment)
model_aliases.cjs:41	VERSION_SUFFIX_PATTERN	yes (manual disable comment)
glob_pattern_helpers.cjs:75	regexPattern	yes (manual disable comment)
handle_agent_failure.cjs:71	AWF_API_PROXY_HOST_RE_SOURCE	no — currently unsuppressed, live warning

5 of 6 sites already carry hand-written disable comments with nearly identical rationale — strong signal the team already treats this as a known false-positive class. The 6th (handle_agent_failure.cjs:71, building COPILOT_ORG_BILLING_ERROR_RE) is structurally identical but has no suppression at all, meaning it currently sits as an untriaged warning (the rule is warn, not error, so it doesn't fail CI).

Filed issue proposing the rule recognize a regex-fragment naming convention (_PATTERN/_RE/_RE_SOURCE/_CHAR/_DELIMITERS suffixes, mirroring the existing escaped-prefix convention) and/or well-formed-regex-source literal detection. This would close the live gap and let all 5 manual disable comments be removed.

Also investigated and ruled out: bare RegExp(...) calls without new (same visitor gap — the rule only listens for NewExpression — but zero live occurrences in the corpus, so not filed per the workflow's ungrounded-theory policy).

Chronic / carried items (unchanged, no action needed)

Tracking notes

• #62317 (require-invalid-date-check-before-compare, created 2026-09-21) and #62560 (no-string-fallback-for-non-string-message, created 2026-09-22) remain open; both are approaching their typical ~1-week first-expiry window based on prior recurrences in this series.
• #63359 (require-fetch-response-body-try-catch chain-unwrap gap) filed 2026-09-25, still open.
• Two chronic themes remain correctly un-refiled after 2+ expiries with zero fresh grounding: try-catch-rule-utils.ts's shared VariableDeclaration-suggestion gap (affects ~14 fs-sync/child-process rules, #57868/#59891) and no-json-stringify-equality's indirect-variable gap (#57869/#59892). Both require a source-level fix this workflow cannot submit (no PR-capable safe-output) — flagging again for a human or PR-capable workflow to pick up.
• Confirmed (again) that 3 issues have had their underlying rule genuinely fixed upstream while the tracker still shows them expired-not-closed rather than closed-as-fixed: #61044, and the require-spawnsync-error-check fix behind the (now-closed) #61543 history. This workflow has no close_issue/add_comment safe-output to reconcile that — needs a human or PR-capable workflow pass.
• core-method-resolve.ts's multi-hop alias-chain theory (would affect 7 consumer rules) remains a real but ungrounded structural gap after 3 dedicated checks — retained as latent-only.

Next actions

• Watch #62317 and #62560 for expiry over the next few days; refile as 2nd-generation recurrences only if they expire still-unfixed.
• Continue the never-reviewed-rule cross-reference method to find fresh audit targets when the open-issues/expiry angle is quiet.
• A human or PR-capable workflow should reconcile the 3 confirmed genuine-fix-but-not-closed issues, and consider tackling the chronic try-catch-rule-utils.ts and no-json-stringify-equality source-level gaps directly via a PR.

Generated by 🤖 ESLint Refiner · claude · agent · 274 AIC · ⌖ 6.82 AIC · ⊞ 6K · ◷

• expires on Sep 26, 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 #63782.