Interview answer drill

Use this Angular interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.

Practice interview questions Follow 30-day foundations study plan Practice more Angular interview questions

What Actually Cancels an HTTP Request in Angular?Frontend interview answer

HighIntermediateAngular

By FrontendAtlas Team · Updated Apr 9, 2026

Interview focus

This Angular interview question tests whether you can distinguish true HttpClient cancellation from ignoring stale responses, explain unsubscribe ownership, and defend the RxJS operator choice.

True request cancellation vs stale response handling
unsubscribe, switchMap, takeUntil, and AsyncPipe cleanup ownership
why mergeMap and ignored callbacks do not cancel old network work

Practice more Angular interview questions

Interview quick answer

In Angular, HTTP requests are canceled by unsubscribing from the Observable, usually via switchMap, takeUntil, async pipe, or manual unsubscribe. The production trap is that many patterns only ignore old responses instead of truly aborting the request.

Full interview answer

Core idea

An Angular HttpClient request is just an Observable wrapper around a browser request. The only thing that can actually cancel it is unsubscribing from that Observable. When you unsubscribe, Angular tells the browser to abort the underlying request (via AbortController or XHR abort).

Action	Does it cancel the network request?	What really happens
Unsubscribe from HttpClient Observable	✅ Yes	Browser request is aborted.
switchMap to a new request	✅ Yes	Previous inner subscription is unsubscribed.
takeUntil emits	✅ Yes	Subscription is torn down → request aborted.
Component destroyed (async pipe)	✅ Yes	AsyncPipe unsubscribes automatically.
Using mergeMap	❌ No	Old requests keep running in parallel.
Ignoring the result in code	❌ No	Network still continues; you just drop the response.

What truly cancels HTTP in Angular?

The classic search example

When users type quickly, you want to cancel old requests and only keep the latest one.

TYPESCRIPT

this.results$ = this.searchControl.valueChanges.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap(term => this.http.get(`/api/search?q=${term}`))
);

Why this cancels old requests

switchMap unsubscribes from the previous inner Observable when a new value arrives. Since HttpClient cancels requests on unsubscribe, the browser request is aborted.

takeUntil pattern (component lifecycle)

TYPESCRIPT

this.http.get('/api/data').pipe(
  takeUntil(this.destroy$)
).subscribe();

ngOnDestroy() {
  this.destroy$.next();
  this.destroy$.complete();
}

Manual teardown also cancels

switchMap is not the only cancel mechanism. If you keep the subscription and call unsubscribe() yourself, Angular aborts the underlying request just the same. That matters in imperative flows like dialogs, temporary polling, or explicit “cancel” buttons.

TYPESCRIPT

let sub = this.http.get('/api/report').subscribe({
  next: data => console.log(data),
  error: err => console.error(err)
});

cancelButton.onclick = () => {
  sub.unsubscribe(); // ✅ real network cancellation
};

Ignoring a result is not cancellation

If code sets a flag like ignoreOldResponses = true but keeps the old subscription alive, the browser request still runs. You only changed what your callback does with the response.

What does NOT cancel the request

Many devs think these cancel HTTP, but they don’t:

Myth	Reality
“I used mergeMap, so old requests are gone”	❌ mergeMap runs everything in parallel. Nothing is canceled.
“I navigated away from the page”	❌ Unless you unsubscribed (async pipe or takeUntil), request keeps running.
“I ignored the result in subscribe”	❌ The network request still completes.
“The server will stop anyway”	❌ The server may continue processing even if client aborts.

Common misconceptions

Important nuance: canceling the browser request vs canceling server work

When Angular aborts the request, the browser connection is closed. The server may or may not stop processing—this depends entirely on server implementation. From the frontend point of view, however, the request is gone.

Angular pattern	Does it cancel HTTP?	Why
AsyncPipe in template	✅ Yes	Auto-unsubscribes when component is destroyed.
switchMap	✅ Yes	Unsubscribes previous inner Observable.
takeUntil / takeUntilDestroyed	✅ Yes	Unsubscribe is triggered by notifier or lifecycle.
mergeMap	❌ No	No cancellation semantics.
shareReplay	⚠️ Depends	May keep the request alive if refCount is false.

Cancellation behavior by pattern

Same flow, different operator, different cancellation behavior

These two snippets look similar, but only one actually aborts old requests when a new query arrives:

TYPESCRIPT

// ✅ Latest-only behavior: previous HttpClient request is unsubscribed
results$ = this.search.valueChanges.pipe(
  debounceTime(250),
  distinctUntilChanged(),
  switchMap(q => this.http.get(`/api/search?q=${q}`))
);

// ❌ Old requests keep running: responses can still arrive out of order
results$ = this.search.valueChanges.pipe(
  debounceTime(250),
  distinctUntilChanged(),
  mergeMap(q => this.http.get(`/api/search?q=${q}`))
);

Senior-level pitfall

Using shareReplay without refCount can keep an HTTP request (or its subscription) alive forever, making it impossible to cancel later even if components unsubscribe.

Interview summary

In Angular, only unsubscribing cancels an HTTP request. Operators like switchMap, takeUntil, and the async pipe cancel requests because they unsubscribe. Operators like mergeMap do not cancel anything—they just ignore or parallelize results. Real cancellation = unsubscribe.