[eslint-refiner] ESLint Refiner — Daily Report 2026-07-11: require-return-after-core-setfailed (rule #13)

[github-actions[bot]]

Overview

Reviewed the newest never-before-analyzed rule in eslint-factory, require-return-after-core-setfailed. A 3-day gap since the last run (2026-07-08) shipped two new rules — index.ts now registers 14 rules (was 12). Led with require-return-after-core-setfailed; no-github-request-interpolated-route remains unreviewed and is queued to lead next run.

Key metrics

Metric	Value
Rules registered (index.ts)	14 (was 12 on 07-08)
New rules since last run	2 (no-github-request-interpolated-route, require-return-after-core-setfailed)
Rule reviewed today	require-return-after-core-setfailed
Issues filed	2 (quality-over-cap; max 3)
Duplicates	0 (only #43948, #43486 open under eslint-factory)
Live core.setFailed sites scanned	~30 non-test .cjs

Findings filed

1. [MED · grounded] addReturn suggestion orphans intended trailing statements. The autofix inserts return; before the statement following core.setFailed(...). On the sole live trigger — lock-issue.cjs:78-79 (core.setFailed(...); core.setOutput("locked", "false");) — applying it makes core.setOutput unreachable, silently dropping the locked step output. The correct human fix is to reorder cleanup before setFailed (as check_workflow_timestamp_api.cjs:424-425 already does).
2. [MED · soundness/latent] Nested-block fall-through false negative. The rule only inspects direct siblings of the setFailed call, so if (!ok) { core.setFailed(msg); } doMore(); is not flagged even though doMore() runs in a failed state — a case the test suite currently enshrines as valid (require-return-after-core-setfailed.test.ts:92). Related: isControlTransfer accepts break/continue unconditionally, so a continue after setFailed inside a loop leaves post-loop code running in a failed state. Ungrounded in the current (disciplined) corpus; filed to harden the rule against future refactors.

Rule health & true negatives

The rule works correctly on its main path: it fires the expected true positive at lock-issue.cjs:78 (setFailed → setOutput) and correctly leaves disciplined sites unflagged — check_permissions.cjs, remove_trigger_label.cjs, run_evals.cjs, upload_assets.cjs, check_command_position.cjs all pair setFailed with return, and check_workflow_timestamp_api.cjs:424-425 orders setOutput before a terminal setFailed. The corpus is disciplined: every live core.setFailed either has a sibling return/throw or is the terminal statement of its function.

Not filed (tracked in repo-memory): alias/destructure blindness (const c = core / const { setFailed } = core) — consistent with prior rules but core is effectively never aliased, so ungrounded and skipped.

Continuity / next run

• Lead next: no-github-request-interpolated-route (14th registered rule, documented in README, still unreviewed). Ground via grep on interpolated/concatenated .request() route args; check alias/getOctokit detection and .concat() gaps.
• Watch: ~1 new rule/day cadence — re-read index.ts first and diff against the tracked rule list to catch multiple new rules per gap.
• Repo-memory updated and pushed (state.json, history.jsonl, findings-2026-07-11.json; 12 KB at limit).

Next actions

• Maintainers: triage the two filed issues against require-return-after-core-setfailed.
• Next run: review no-github-request-interpolated-route.
• Standing doc debt: several of the 14 rules (incl. require-return-after-core-setfailed) are undocumented in the README.

Generated by 🤖 ESLint Refiner · 349.7 AIC · ⌖ 12.6 AIC · ⊞ 4.6K · ◷

• expires on Jul 11, 2026, 10:10 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by ESLint Refiner.

A newer discussion is available at Discussion #45052.