[eslint-refiner] ESLint Refiner Daily Report — 2026-09-14 #60758
Closed
Replies: 1 comment
|
This discussion was automatically closed because it expired on 2026-09-15T05:37:55.673Z.
|
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
ESLint Refiner — Daily Report (2026-09-14)
Reviewed 7 previously-unexamined
eslint-factoryrules against the liveactions/setup/js/**corpus. Filed 1 grounded false-positive finding; 6 hypotheses were disproven under live-corpus grounding and correctly not filed.Key metrics
Issue filed
no-string-fallback-for-non-string-message: false positive on a type-narrowed catch-param aliasLive site:
actions/setup/js/safeoutputs_cli.cjs:45-48. The rule flagsString(error)as "stringifying the wrong container" because it structurally compares identifier names (errorvs. the testederr.messagechain) without recognizing thaterris declared asconst err = /** @type {...} */ error ?? {}— a type-narrowing alias of the same value, not an unrelated container.String(error)andString(err)are identical whenevererroris truthy, andString(error)is actually more correct thanString(err)would be in the one case they diverge (falsyerror). No existing test covers this alias shape.Detail: rules reviewed with no issue filed
6 rules/hypotheses investigated, no grounded gap found
prefer-core-logging— zero liveconsole.log/info/debug(...)call sites in the corpus; the one reference-not-call infrontmatter_hash_pure.cjs:70is correctly unflagged by design.require-page-counter-increment-in-while-true-loop— checked all 8 livewhile (true)loops in the corpus; each either isn't a page-counter loop (usesreader.read(),readBuffer.readMessage(), byte-count loops, GraphQL cursors, etc.) or correctly increments its counter.require-nan-check-after-split-index-parse— zero liveparseInt/parseFloat(...split(...)[index])call sites in the corpus.no-throw-plain-object— exhaustively checked all 35 livethrow {...}sites acrossmcp_server_core.cjs(11) andsafe_outputs_handlers.cjs(24); every one is a clean{code: <negative literal>, message, data?}JSON-RPC shape, correctly exempted.no-core-error-then-{setfailed,process-exit,process-exitcode}family — hypothesized a nested-if-block blind spot (aprocess.exit/exitCodenested inside anifaftercore.error(...)isn't correlated sinceIfStatementisn't a recognized control-transfer statement). Zero live matches found via corpus search — disproven, doesn't meet the "latent but broadly-applicable idiom" bar from a prior precedent (which required a 23-file idiom; this hypothesis has zero occurrences).prefer-actions-exec-over-child-process— reviewed at source level only (mature design: handlespromisify(), ChildProcess-handle retention, and async-conversion cascades). Not yet exhaustively grounded against live call sites — carried forward as a next-run priority rather than filed speculatively.Next actions
prefer-actions-exec-over-child-processagainst the ~18 non-test files that bothrequire("child_process")and carry the@actions/github-scriptreference marker.require-error-code-in-thrown-error(100+ importing files — needs a targeted strategy, not exhaustive review).nextPriorities.References:
Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
api.anthropic.comTo allow these domains, add them to the
network.allowedlist in your workflow frontmatter:See Network Configuration for more information.
All reactions