Avoid Async/Await Pitfalls in TypeScript

I was asked by one summer intern about the asynchronous code in our Angular project. He’d been staring at a service method for twenty minutes, convinced it was broken, when really it was just waiting patiently, one await at a time, for three requests that had no reason to block each other. I pulled up a blank file and said, “Let’s fix this together,” and by the end of the afternoon we’d walked through the five mistakes I see most often in async TypeScript. He asked good questions, so I wrote the answers down.

Async/await is the modern standard for asynchronous JavaScript/TypeScript, but misuse causes hard-to-debug issues: silent freezes, unhandled rejections, redundant concurrency, and over-scoped error handling. Here are 5 common async/await pitfalls in frontend production, paired with idiomatic Angular alternatives.

Pitfall 1: Unintentional Sequential Requests#

The Bug: Chaining independent await calls sequentially adds up latency instead of overlapping it.

1
// BAD: Sequential execution (~900ms total)
2
const getInfo = async () => {
3
  const user = await getUser();
4
  const list = await getList();
5
  const banner = await getBanner();
6
};

The Fix: Run independent requests concurrently with Promise.all:

1
// GOOD: Concurrent execution (limited to the slowest request)
2
const getInfo = async () => {
3
  const [user, list, banner] = await Promise.all([
4
    getUser(),
5
    getList(),
6
    getBanner()
7
  ]);
8
};

The Angular Way: Angular relies on RxJS Observables via HttpClient. Use forkJoin to run HTTP requests in parallel:

1
import { forkJoin } from 'rxjs';
2

3
forkJoin({
4
  user: this.http.get('/api/user'),
5
  list: this.http.get('/api/list'),
6
  banner: this.http.get('/api/banner')
7
}).subscribe(({ user, list, banner }) => {
8
  // Executes in parallel, emits once all complete
9
});

Pitfall 2: All-or-Nothing Failures with Promise.all#

The Bug: Promise.all rejects immediately if any single request fails, blocking the whole page unnecessarily.

The Fix: Use Promise.allSettled to resolve all promises regardless of individual rejections, enabling partial UI rendering:

1
const results = await Promise.allSettled([
2
  getUser(),
3
  getList(),
4
  getBanner()
5
]);

The Angular Way: In RxJS, an error on any inner stream terminates the combined stream. Intercept errors per request with catchError and return a safe fallback:

1
import { forkJoin, of } from 'rxjs';
2
import { catchError } from 'rxjs/operators';
3

4
forkJoin({
5
  user: this.userService.getUser().pipe(catchError(err => of(null))),
6
  list: this.listService.getList().pipe(catchError(err => of([]))),
7
  banner: this.bannerService.getBanner().pipe(catchError(err => of(null)))
8
}).subscribe(data => {
9
  // Partial failures won't break the entire page
10
});

Pitfall 3: Forgetting `await` (“Ghost Async Bugs”)#

The Bug: async functions always return a Promise. Omitting await yields the Promise wrapper, not the resolved value:

1
const getData = async () => request.get('/api/list');
2

3
// BAD: Assigns a Promise object instead of resolved data
4
const list = getData();

The Fix: Always await or .then() the invocation.

The Angular Way: Pass the Observable directly to the template using the async pipe, which handles subscription and unsubscription automatically:

1
<!-- Angular Preferred: Declarative unwrapping in templates -->
2
<div *ngIf="user$ | async as user">
3
  {{ user.name }}
4
</div>

For imperative logic that needs a Promise (Angular v12+), use firstValueFrom:

1
import { firstValueFrom } from 'rxjs';
2

3
const list = await firstValueFrom(this.http.get<List>('/api/list'));

Pitfall 4: Over-Scoped try/catch Blocks#

The Bug: Wrapping multiple async calls in one monolithic try/catch obscures which request failed and blocks unrelated operations:

1
// BAD: Broad error boundary
2
try {
3
  const user = await getUser();
4
  const list = await getList();
5
} catch (err) {
6
  showGlobalError('Request failed');
7
}

The Fix: Isolate try/catch boundaries per request to enable local degradation and clearer debugging.

The Angular Way: Use an HttpInterceptor for cross-cutting HTTP errors, and local RxJS catchError for component-level fallbacks:

1
this.userService.getUser().pipe(
2
  catchError(error => {
3
    this.notifier.showLocalWarning('User data unavailable');
4
    return of(fallbackUser);
5
  })
6
).subscribe();

Pitfall 5: Using `await` Inside `Array.prototype.forEach`#

The Bug: forEach is strictly synchronous and does not wait for promises inside its callback:

1
// BAD: Execution continues before loop async tasks finish
2
items.forEach(async (item) => {
3
  await processItem(item);
4
});
5
console.log('Done'); // Logs immediately!

The Fix: Use a for...of loop for sequential async iteration, or map + Promise.all for parallel execution:

1
// Sequential
2
for (const item of items) {
3
  await processItem(item);
4
}

The Angular Way: RxJS provides explicit concurrency operators for collections or streamed actions:

concatMap: sequential execution (equivalent to for...of + await)
mergeMap: parallel execution (equivalent to Promise.all)
switchMap: cancels the previous pending request when a new one arrives

1
import { from } from 'rxjs';
2
import { concatMap } from 'rxjs/operators';
3

4
// Process items sequentially in RxJS
5
from(items).pipe(
6
  concatMap(item => this.http.post('/api/process', item))
7
).subscribe();

Summary Matrix#

Problem Scenario	Vanilla JS Solution	Angular Standard (RxJS Idiom)
Independent Parallel Requests	`Promise.all()`	`forkJoin({...})`
Fault-Tolerant Requests	`Promise.allSettled()`	`forkJoin` + `catchError(of(null))`
Template Data Binding	`await fn()`	AsyncPipe (`item$ \| async`)
Error Isolation	Local `try/catch`	`catchError` operator / `HttpInterceptor`
Sequential Iteration	`for...of` loop	`concatMap` operator