no-await-in-loop

Type-unaware

Disallow await inside loops without considering concurrency implications. This rule is part of eslint-plugin-reliability and provides LLM-optimized error messages with concurrency pattern suggestions.

Quick Summary

Aspect	Details
Severity	Warning (performance)
Auto-Fix	❌ No (suggests refactoring patterns)
Category	Quality
ESLint MCP	✅ Optimized for ESLint MCP integration
Best For	Performance-critical applications, API batch operations

Rule Details

Why This Matters

Issue	Impact	Solution
⚡ Performance	N*latency instead of 1x	Use Promise.all()
🔄 Sequential Bottleneck	Blocks event loop	Concurrent execution
📊 Scalability	Slow with large datasets	Batch processing
🎯 Resource Usage	Inefficient API calls	Parallelization

What is reported

An await that runs on every iteration: in the loop body, in a nested block of it, or in a per-iteration header slot (a for test or update, a while / do-while condition). Not reported:

an await in a slot evaluated once before iterating (the for…of / for…in iterable, a for initialiser);
an await inside a function defined in the loop — it runs in its own async context;
a loop that carries an awaited value into its next iteration: a cursor the loop test reads, an accumulator passed to the next await, a status that decides a break or return. Those iterations cannot run concurrently, so the sequential loop is the correct shape.

Configuration

Option	Type	Default	Description
`allowForOf`	`boolean`	`false`	Allow await in for-of loops
`allowWhile`	`boolean`	`false`	Allow await in while and do-while loops
`checkConcurrency`	`boolean`	`true`	Shapes the advice in the message; never whether a loop is reported

Examples

❌ Incorrect

// Sequential execution - N * latency
async function fetchAllUsers(ids: string[]) {
  const users = [];
  for (const id of ids) {
    const user = await fetchUser(id);  // ❌ Await in loop
    users.push(user);
  }
  return users;
}

// Also problematic
async function processItems(items: Item[]) {
  for (let i = 0; i < items.length; i++) {
    await processItem(items[i]);  // ❌ Await in loop
  }
}

✅ Correct

// Concurrent execution - 1x latency (max)
async function fetchAllUsers(ids: string[]) {
  const users = await Promise.all(
    ids.map(id => fetchUser(id))
  );
  return users;
}

// With error handling
async function processItems(items: Item[]) {
  const results = await Promise.allSettled(
    items.map(item => processItem(item))
  );
  return results;
}

// Controlled concurrency with p-map
import pMap from 'p-map';

async function fetchWithLimit(urls: string[]) {
  return pMap(urls, fetchUrl, { concurrency: 5 });
}

Configuration Examples

Basic Usage

{
  rules: {
    'reliability/no-await-in-loop': 'warn'
  }
}

Allow for-of Loops

{
  rules: {
    'reliability/no-await-in-loop': ['warn', {
      allowForOf: true,
      allowWhile: false
    }]
  }
}

Strict Mode

{
  rules: {
    'reliability/no-await-in-loop': ['error', {
      allowForOf: false,
      allowWhile: false,
      checkConcurrency: true
    }]
  }
}

Refactoring Patterns

Sequential to Parallel

// ❌ Before: 10 items = 10 * 100ms = 1000ms
for (const item of items) {
  await process(item);
}

// ✅ After: 10 items = ~100ms (parallel)
await Promise.all(items.map(process));

With Rate Limiting

// Using p-map for controlled concurrency
import pMap from 'p-map';

async function fetchAll(urls: string[]) {
  return pMap(urls, fetch, { concurrency: 3 });
}

When Sequential is Required

The rule stays silent when an iteration needs the previous one's awaited result:

// ✅ Not reported: the cursor the test reads comes from the await
let cursor = start;
while (cursor) {
  const page = await getPage(cursor);
  cursor = page.next;
}

// ✅ Not reported: the accumulator feeds the next await
async function processSequentially(items: Item[]) {
  const results = [];
  for (const item of items) {
    // Dependencies between iterations require sequential
    const result = await processWithPrevious(item, results);
    results.push(result);
  }
  return results;
}

When Not To Use

Scenario	Recommendation
📊 Order-dependent ops	Use `allowForOf: true` or disable rule
🔒 Rate-limited APIs	Use controlled concurrency libraries
💾 Memory constraints	Sequential may be necessary
🔄 Transaction chains	Sequential execution required

Comparison with Alternatives

Feature	no-await-in-loop	eslint built-in	unicorn
Concurrency Check	✅ Yes	❌ No	⚠️ Limited
Loop Type Config	✅ Per-type	❌ No	❌ No
LLM-Optimized	✅ Yes	❌ No	❌ No
ESLint MCP	✅ Optimized	❌ No	❌ No
Pattern Suggestions	✅ Yes	❌ No	⚠️ Limited

detect-n-plus-one-queries - Detects N+1 query patterns
no-blocking-operations - Detects blocking operations

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Dynamic Variable References

Why: Static analysis cannot trace values stored in variables or passed through function parameters.

// ❌ NOT DETECTED - Value from variable
const value = externalSource();
processValue(value); // Variable origin not tracked

Mitigation: Implement runtime validation and review code manually. Consider using TypeScript branded types for validated inputs.

Wrapped or Aliased Functions

Why: Custom wrapper functions or aliased methods are not recognized by the rule.

// ❌ NOT DETECTED - Custom wrapper
function myWrapper(data) {
  return internalApi(data); // Wrapper not analyzed
}
myWrapper(unsafeInput);

Mitigation: Apply this rule's principles to wrapper function implementations. Avoid aliasing security-sensitive functions.

Imported Values

Why: When values come from imports, the rule cannot analyze their origin or construction.

// ❌ NOT DETECTED - Value from import
import { getValue } from './helpers';
processValue(getValue()); // Cross-file not tracked

Mitigation: Ensure imported values follow the same constraints. Use TypeScript for type safety.

Use this rule

npm install -D oxlint-plugin-reliability

npm install -D oxlint-plugin-reliability

.oxlintrc.json

{
  "jsPlugins": ["oxlint-plugin-reliability"],
  "rules": {
    "reliability/no-await-in-loop": "error"
  }
}

.oxlintrc.json

{  "jsPlugins": ["oxlint-plugin-reliability"],  "rules": {    "reliability/no-await-in-loop": "error"  }}

vite.config.ts

import { defineConfig } from 'vite-plus';

export default defineConfig({
  lint: {
    jsPlugins: ['oxlint-plugin-reliability'],
    rules: {
      'reliability/no-await-in-loop': 'error',
    },
  },
});

vite.config.ts

import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-reliability'],    rules: {      'reliability/no-await-in-loop': 'error',    },  },});

oxlint-plugin-reliability re-exports eslint-plugin-reliability/oxlint: the same rules under the same IDs, and no ESLint install. Why oxlint.

Did this rule catch something? Star the repo to get new CWE coverage as we ship it — or follow the AI-code-security benchmarks behind these rules.

Follow the benchmarks Star on GitHub

no-await-in-loop

Quick SummaryCopy Anchor Link

Rule DetailsCopy Anchor Link

Why This MattersCopy Anchor Link

What is reportedCopy Anchor Link

ConfigurationCopy Anchor Link

ExamplesCopy Anchor Link

❌ IncorrectCopy Anchor Link

✅ CorrectCopy Anchor Link

Configuration ExamplesCopy Anchor Link

Basic UsageCopy Anchor Link

Allow for-of LoopsCopy Anchor Link

Strict ModeCopy Anchor Link

Refactoring PatternsCopy Anchor Link

Sequential to ParallelCopy Anchor Link

With Rate LimitingCopy Anchor Link

When Sequential is RequiredCopy Anchor Link

When Not To UseCopy Anchor Link

Comparison with AlternativesCopy Anchor Link

Related RulesCopy Anchor Link

Further ReadingCopy Anchor Link

Known False NegativesCopy Anchor Link

Dynamic Variable ReferencesCopy Anchor Link

Wrapped or Aliased FunctionsCopy Anchor Link

Imported ValuesCopy Anchor Link