no-empty-catch-block: rationale comments without a magic keyword still flagged (live in ledger_store.cjs)

[github-actions]

Summary

no-empty-catch-block's intentional-ignore comment matcher recognizes a fixed set of trigger phrases (intentional, best-effort/best effort, non-fatal, ignore(d/s), fall-through/fall through, no-op, or swallow...because/since). A comment that clearly documents why an empty catch is safe, but doesn't use one of those exact words, is still flagged as an undocumented empty catch — producing an avoidable warning on code that already explains its own rationale.

Live grounding

Two brand-new empty catch blocks in actions/setup/js/ledger_store.cjs (merged in #64354, the ledger configuration feature) hit this exact gap:

// ledger_store.cjs:741-746
} finally {
  try {
    fs.closeSync(fd);
  } catch {
    // Closing after fsync must not turn a durable append into a reported failure.
  }
}

// ledger_store.cjs:773-778
} finally {
  try {
    fs.closeSync(directory);
  } catch {
    // Closing after the directory sync must not reject a published shard.
  }
}

Both comments clearly state the design rationale (don't let a close-after-durability-guarantee failure surface as an operation failure), but neither contains intentional, best-effort, non-fatal, ignore, fall-through, no-op, or swallow. commentSignalsIntentionalIgnore (eslint-factory/src/rules/no-empty-catch-block.ts:25-29) returns false for both, so hasIntentionalIgnoreComment reports them as undocumented — despite being adjacent, same-block sibling code in this very file (ledger_store.cjs:737-739 and :763-765, both worded "Best-effort cleanup: ...") that correctly avoids the warning purely because it happens to include the word "Best-effort".

This means two developers writing equally-intentional rationale comments in the same file get inconsistent lint outcomes based on incidental word choice, not on whether the catch is actually documented.

Suggested fix

Broaden commentSignalsIntentionalIgnore beyond the closed keyword list — e.g., also accept comments that name a specific consequence being avoided (must not fail/reject/turn ... into a failure, should not surface, is safe because/since), or relax the bar to "any comment inside the catch block referencing the specific error-handling behavior" rather than requiring one of ~10 hardcoded phrases. At minimum, add must not <verb> / should not <verb> (already partially handled only for the negation-of-ignore case in negatedIntentionalIgnoreCommentRe) as a positive signal, not just a negation guard.

Acceptance criteria

• Both ledger_store.cjs:744-746 and :776-778 are recognized as documented (no noEmptyCatch warning) without changing their comment wording.
• Existing test cases in no-empty-catch-block.test.ts (including the negation cases like "must not silently swallow") continue to pass.
• New test cases cover a "must not (consequence)" style rationale comment as a positive signal.

Generated by 🤖 ESLint Refiner · claude · agent · 285.9 AIC · ⌖ 5.67 AIC · ⊞ 4.8K · ◷

• expires on Oct 6, 2026, 9:37 PM UTC-08:00