Practice Questions

Interview answer drill

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

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

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

HighIntermediateAngular

By FrontendAtlas Team · Updated May 31, 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

Yes: unsubscribing from an Angular HttpClient Observable aborts the in-progress browser request. In interviews, explain that switchMap, takeUntil, and AsyncPipe cancel because they unsubscribe; ignoring a stale response is not cancellation.

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).

Official docs anchor

Angular's <a href="https://angular.dev/guide/http/making-requests" target="_blank" rel="noopener">Making requests</a> guide describes HttpClient Observables as cold request blueprints: subscribing starts the browser request, and unsubscribing aborts an in-progress request. That is why AsyncPipe, switchMap, and lifecycle teardown can cancel stale HTTP work.

Do you need to unsubscribe from every HttpClient call?

Not usually for memory-leak prevention after a normal response, because Angular HttpClient Observables usually complete when the response returns. But yes, you should unsubscribe when the request is still in flight and the UI intent or component lifetime has moved on. That teardown aborts the browser request and avoids stale callbacks touching destroyed UI.

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.

takeUntilDestroyed pattern (component lifecycle)

In modern Angular, prefer takeUntilDestroyed() for manual subscriptions tied to a component lifetime. The older takeUntil(destroy$) subject pattern is still common in older codebases, but it should not be the first answer for new Angular code.

TYPESCRIPT

import { HttpClient } from '@angular/common/http';
import { DestroyRef, inject } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

export class DataComponent {
  private readonly destroyRef = inject(DestroyRef);
  private readonly http = inject(HttpClient);

  ngOnInit() {
    this.http.get('/api/data').pipe(
      takeUntilDestroyed(this.destroyRef)
    ).subscribe();
  }
}

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.

How to verify this in Angular tests

In HttpClient tests, Angular's <a href="https://angular.dev/api/common/http/testing/TestRequest" target="_blank" rel="noopener">TestRequest.cancelled</a> flag is the official proof point. Subscribe to the request, capture it with HttpTestingController, unsubscribe before flushing, and assert that the request was marked cancelled. <a href="https://angular.dev/api/common/http/testing/HttpTestingController" target="_blank" rel="noopener">HttpTestingController.verify({ ignoreCancelled: true })</a> is useful only when cancelled requests are intentionally not the assertion target; do not use it to hide missing expectOne checks.

TYPESCRIPT

const sub = service.loadUser().subscribe();
const req = httpMock.expectOne('/api/user');

sub.unsubscribe();

expect(req.cancelled).toBeTrue();

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}`))
);

When switchMap is the wrong answer

switchMap is right for latest-only reads like typeahead, autocomplete, filters, and route-driven detail fetches. It is the wrong default for save, payment, checkout, analytics, or mutation flows where every request must complete. In those cases, choose the flattening operator from the UX contract: concatMap to queue writes, mergeMap to allow safe parallel writes, or exhaustMap to ignore repeat clicks while one request is already running.

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.