[eslint-refiner] ESLint Refiner — Daily Report (2026-08-18)

[github-actions[bot]]

This run had a 41-day gap since the last refinement pass (2026-07-08). In that time eslint-factory grew from 12 to 51 shipped rules — a backlog of 36 never-reviewed rules. This run reviewed the 3 newest rules in src/index.ts and filed 2 grounded issues; the third rule had nothing new to report.

Key metrics

• Rules shipped: 51 (was 12 as of last run)
• Rules reviewed this run: 3 — require-lastindex-reset-before-global-exec-loop, require-page-counter-increment-in-while-true-loop, no-empty-catch-block
• Issues filed: 2 (non-duplicate, grounded in live actions/setup/js/**/*.cjs code)
• Rules reviewed ≥1× (lifetime): 15 / 51
• Backlog: 36 rules awaiting a first review

Issues filed

1. require-lastindex-reset-before-global-exec-loop — false positive on loops that always exhaust naturally
   Flags actions/setup/js/temporary_id.cjs:649 (extractTemporaryIdReferences), where a shared g-flag regex is reused across a for loop's iterations with no reset. The loop body has no break/return/throw, so it always drains to natural exhaustion and the JS engine auto-resets lastIndex to 0 — there's nothing to fix, but the rule reports it anyway because it only checks for a textual reset, not whether the loop can exit early.

2. require-page-counter-increment-in-while-true-loop — misses the standard GitHub pagination idiom
   The rule only looks at the single statement immediately preceding a while (true) loop to find a counter. When a sibling const perPage = 100; sits between let page = 1; and the loop — the standard shape for GitHub REST pagination — the rule finds zero counters and silently skips the loop entirely. Confirmed in two real call sites: report_failed_jobs.cjs:75-78 and add_comment.cjs:277-281. Both happen to increment correctly today, but the rule currently provides no regression protection for either.

Rule-by-rule detail (this run)

require-lastindex-reset-before-global-exec-loop

• Design: flags module-scope g/y regex literals reused in a while ((m = RE.exec(x)) !== null) loop lacking a textual RE.lastIndex = reset earlier in the enclosing function. Purely syntactic — no control-flow analysis of whether the loop can exit early.
• True negatives confirmed: replaceTemporaryIdReferences (temporary_id.cjs:104) and replaceArtifactUrlReferences (temporary_id.cjs:551) both correctly reset before their loops and are correctly left unflagged.
• False positive: extractTemporaryIdReferences (temporary_id.cjs:649) reuses TEMPORARY_ID_PATTERN across 3 text fields (body/title/description) with no reset, but the loop body only calls pure, non-throwing helpers — verified normalizeTemporaryId is just String()/substring()/toLowerCase(). No early exit exists, so the loop is safe by construction.
• Suggested fix: check the loop body for Break/Return/Throw/outer-Continue before reporting; skip if none found.

require-page-counter-increment-in-while-true-loop

• Design: for a while (true) { ...; break; } loop, looks for a let <counter> = <number>; declaration as the single statement immediately preceding the loop, then checks the loop body increments it.
• Gap: getCountersImmediatelyBefore() only inspects parent.body[index - 1]. A sibling const perPage = 100; between the counter and the loop (the standard REST pagination idiom used pervasively in this codebase) becomes the "previous" statement instead, which is a const — so the function returns [] and the counter is never checked.
• Grounded at report_failed_jobs.cjs:75-78 (let page = 1; const perPage = 100; while (true) {...}) and add_comment.cjs:277-281 (identical shape in findCommentsWithTrackerId). Both loops correctly increment page today, but neither is actually validated by the rule.
• Suggested fix: walk backward through a run of consecutive VariableDeclaration statements before the loop, not just the single adjacent one.

no-empty-catch-block (3rd review, no new finding)

• No live non-test empty catch blocks exist in actions/setup/js/**/*.cjs (test files are already excluded from lint config).
• Already well covered by 2 prior closed issues: eslint-factory: no-empty-catch-block comment regex misses common real-world phrasings (grounded FPs) #52844 (comment-regex phrasing gaps) and eslint-factory: no-empty-catch-block has no coverage for empty Promise .catch(() => {}) entrypoint handlers #52845 (Promise .catch(() => {}) coverage) — both appear to have been addressed given the rule's current sophistication (negation-aware regex, swallow+because heuristic, etc).
• One theoretical gap remains ungrounded: the intentional-ignore word list (ignore, no-op, etc.) could suppress a warning on a genuinely accidental empty catch if an unrelated comment happens to contain one of those words nearby. No live example found, so not filed.

Next actions

• 36 of 51 rules still need a first review. Next runs should continue through src/index.ts in order and ground findings against actions/setup/js/**/*.cjs.
• Once the 2 issues above are addressed, re-verify temporary_id.cjs:649 is no longer flagged and that report_failed_jobs.cjs/add_comment.cjs pagination loops are now actually covered by the counter rule.
• Repo-memory (memory/eslint-refiner branch) updated with the full unreviewed-rule backlog and this run's grounded findings for continuity.

Generated by 🤖 ESLint Refiner · agent · 212 AIC · ⌖ 4.87 AIC · ⊞ 5.3K · ◷

• expires on Aug 18, 2026, 9:29 PM UTC-08:00