There's a known false positive that isn't mitigated: await immediately followed by a loop-terminating return/break still gets flagged, even though there's no real sequential-execution cost since the loop won't continue.

async function foo(arr) {
  for (const x of arr) {
    const r = await fetch(x);
    if (r.ok) return r; // loop ends right after — flagging this await is noisy
  }
}

This matches upstream eslint/eslint#14700, which was closed as "working as intended" since it's out of scope for the base no-await-in-loop rule. Since we're wrapping it for a Sonar-specific rule, could we add a decorator to suppress the report when the await is the last statement before a return/break that exits the loop? Otherwise this will be a live source of noise on early-exit-after-await code, which is a pretty common pattern.

Thinking through how to implement the suppression, I see three options:

1. Only suppress when the await is unconditionally followed by return/break (no branching). This means the loop always exits after its first iteration — nonsense code, since it wouldn't be written as a loop.
2. Suppress whenever a return/break appears anywhere later in the loop body, regardless of whether it's on the same path as the await, e.g.:

   for (const id of ids) {
     const item = await fetch(id);
     if (item.matches(query)) return item;
   }

   Easy to implement, but carries the potential for a high false-negative rate, since the presence of a later return/break doesn't tell us whether that path is actually taken on a given iteration.
3. A heuristic somewhere in between 1 and 2
4. Real reachability/CFG analysis to determine whether all paths after the await exit the loop. SonarJS doesn't currently have a control-flow-graph engine for JS/TS rules, so this would require building that piece first.

See also eslint/eslint#14700 where this FP was discussed, but no heuristic was ever really speced.

What did you have in mind? If it's 4), that's a separate SE-engine question we'd want to scope on its own rather than bundle into this rule's first cut.

I'd lean toward option 2. Even a return/break later in the loop body that isn't strictly on the await's execution path is a strong enough signal. That shape of code (search-and-early-exit) is exactly where sequential awaiting is idiomatic, not accidental. It shows the author already intended each promise to resolve one at a time before deciding whether to keep going, so I'd rather accept the occasional false negative than keep flagging that pattern as a bug. What do you think?

Ran the actual numbers instead of guessing. Classified all 247 ruling findings by control-flow shape relative to the flagged await:

• 8/247 (3.2%) are option-1 territory: every path after the await unconditionally exits the loop.
• 30/247 (12.1%) are option-2-only: a return/break exists later in the loop body, but on a different path than the await's own.
• 206/247 (83.4%) have no later return/break at all.

Option 2 would additionally suppress those 30. I classified each of the 30 for TP/FP against the independent-iteration test (shared state / dependency between iterations / retry-backoff / rate-limited / resource-bounded / inherently-sequential = FP; independent = TP): 14 TP / 16 FP.

So option 2 would introduce ~14 new false negatives (real, independent-iteration cases it would wrongly suppress) — things like for (const path of paths) { if (await pathExists(path)) return path; } in editors/darwin.ts/linux.ts/win32.ts, find-account.ts, dev_build_cache.ts — the "search a small list, return on first hit" idiom, occurring independently across several codebases in the corpus, not a one-off. It would also incidentally suppress 16 findings that were already FP for unrelated reasons (pagination, listener chains, retry loops, etc.) — those would go away regardless.

Does a ~14-in-247 (5.7% of all findings) false-negative rate seem like it's worth taking, against the noise reduction it buys?

Test coverage gap: unit.test.ts doesn't exercise a few cases that the underlying ESLint no-await-in-loop logic does handle:

• await in the test/update clause of a classic for(;;) loop, e.g. for (let i = 0; await cond(i); i++) { ... }
• await using declarations inside a loop, e.g. for (const x of arr) { await using r = acquire(); }
• await nested inside intermediate control flow (e.g. if) within the loop body, to confirm detection still works through non-function nesting:

  async function foo(arr) {
    for (let i = 0; i < arr.length; i++) {
      if (arr[i]) {
        await bar(arr[i]);
      }
    }
  }

Could we add valid/invalid cases for these? Without them, a future ESLint upgrade or refactor of the decorator could silently regress any of these without any test catching it.