[eslint-refiner] ESLint Refiner Daily Report 2026-08-05

[github-actions[bot]]

ESLint Refiner — Daily Report (2026-08-05)

Reviewed the newest custom rule and filed two grounded refinement issues. Also surfaced a large review backlog that's built up since the last logged run.

Key metrics

Metric	Value
Rules registered in eslint-factory	36 (up from 12 at last logged run, 2026-07-08)
Rules reviewed today	1 — require-nan-check-after-env-numeric-parse (newest, added 2026-08-03, PR #49962)
Issues filed today	2 (non-duplicate, both grounded in live actions/setup/js code)
Never-reviewed rules remaining	24 (backlog — see below)
Open issues re-confirmed still relevant	#49914 (no-child-process-interpolated-command), #50267 (README doc debt), #49669 (regexp interpolation)

Backlog note

27 days elapsed since the last logged review run, during which 24 new rules shipped without a corresponding review (eslint-miner has been landing roughly one new rule/day). This run picked the newest rule per the established "lead with the newest never-reviewed rule" convention, but the backlog itself is now the biggest structural risk to this workflow's usefulness — a quarter of the ruleset has never had a false-positive/false-negative pass. Recommend future runs either increase throughput (2-3 rules/run) or explicitly work the backlog oldest-first for a few runs to pay it down. Tracked in repo-memory for continuity.

Findings: require-nan-check-after-env-numeric-parse

This rule flags parseInt/parseFloat/Number.parseInt/Number.parseFloat/Number() calls on process.env values that are never checked with isNaN()/Number.isNaN(). Grounding against real call sites in actions/setup/js/** turned up two independent, live defect classes:

Issue 1 — False positives: Number.isFinite() and truthiness guards not recognized

The rule's guard-detector only recognizes isNaN(x) / Number.isNaN(x). Four live sites are already correctly guarded but get flagged anyway:

• build_checkout_manifest.cjs:26-28 — guarded with !Number.isFinite(count) || count < 0
• check_workflow_timestamp_api.cjs:117,123 — guarded with Number.isFinite(runId)
• awf_reflect.cjs:147-148 — guarded with Number.isFinite(configuredDelay) && configuredDelay >= 0
• write_daily_aic_usage_cache.cjs:51-52 — guarded with if (!runId) (NaN is falsy, so this correctly rejects it)

Acceptance criteria: recognize Number.isFinite/isFinite calls and direct truthiness checks (if (!x), if (x), ternary test position) as valid guards; add tests for all four patterns; re-verify the four live sites stop being flagged.

Issue 2 — False negative: ternary-wrapped parse call escapes detection entirely, real bug risk

The rule only tracks a variable when its declarator's init is directly a CallExpression. When the whole parse call is wrapped in a ternary — const x = process.env.FOO ? parseInt(process.env.FOO, 10) : default — the variable is never tracked, guarded or not.

Live and risky: safe_outputs_handlers.cjs:480-482 sets maxSizeKB this way with zero NaN guard anywhere in the file, then compares sizeKB > maxSizeKB. A malformed GH_AW_ASSETS_MAX_SIZE_KB env var silently disables the asset size limit (NaN comparisons are always false) — exactly the failure mode this rule exists to catch, but invisible to it today.

Acceptance criteria: unwrap ConditionalExpression inits and check both branches for a numeric-parse-from-env call; add an invalid-case test for this shape; keep existing ternary-inside-argument tests passing; verify the safe_outputs_handlers.cjs:480 pattern gets flagged.

Confirmed the rule's core detection (bare, unguarded parseInt(process.env.X)-style declarations) works correctly as true positives/negatives at five other live sites: push_repo_memory.cjs, notify_comment_error.cjs, check_rate_limit.cjs, safe-outputs-mcp-server.cjs, handle_noop_message.cjs.

Issues created

1. require-nan-check-after-env-numeric-parse: false positives on Number.isFinite() and truthiness NaN guards
2. require-nan-check-after-env-numeric-parse: ternary-wrapped env parse escapes detection, risking silent bypass of file-size guard

Next actions

• Track resolution of both issues; re-verify the grounded sites once fixes land.
• Next run: continue down the 24-rule backlog (repo-memory notes require-return-after-core-setfailed, 2026-07-10, as the longest-unreviewed candidate) or pick up whatever new rule ships after 2026-08-03.
• Repo-memory (memory/eslint-refiner branch) updated with full findings, grounding evidence, and the backlog note for continuity.

Generated by 🤖 ESLint Refiner · agent · 155 AIC · ⌖ 30.9 AIC · ⊞ 4.9K · ◷

• expires on Aug 5, 2026, 10:14 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-08-06T06:14:29.776Z.

Closed by Workflow