Timeout interceptor in NestJS - Mini Project: Build & Apply

Timeout Interceptor in NestJS

📖 Scenario: You are building a NestJS backend API that needs to cancel requests that take too long. This helps keep your server responsive and avoids waiting forever for slow operations.

🎯 Goal: Create a TimeoutInterceptor that cancels any request taking longer than a set time limit.

📋 What You'll Learn

Create a class called TimeoutInterceptor that implements NestInterceptor

Add a constructor that accepts a timeout value in milliseconds

Use rxjs operators to apply the timeout to the request handling

Throw a RequestTimeoutException if the timeout is exceeded

💡 Why This Matters

🌍 Real World

Timeout interceptors help keep backend APIs responsive by cancelling slow requests, improving user experience and resource usage.

💼 Career

Understanding interceptors and RxJS operators is essential for backend developers working with NestJS to build robust and maintainable APIs.

1

Create the TimeoutInterceptor class

Create a class called TimeoutInterceptor that implements NestInterceptor from @nestjs/common. Import Injectable and decorate the class with it.

NestJS

import { Injectable, NestInterceptor } from '@nestjs/common';

// Your code here

Hint

Remember to import Injectable and NestInterceptor from @nestjs/common and decorate your class with @Injectable().

2

Add a constructor with timeout value

Add a constructor to TimeoutInterceptor that accepts a single parameter called timeout of type number. Store it as a private readonly property.

NestJS

import { Injectable, NestInterceptor } from '@nestjs/common';

@Injectable()
export class TimeoutInterceptor implements NestInterceptor {
  // Add a constructor with a private readonly number parameter called timeout
  // Your code here
}

Hint

Use constructor(private readonly timeout: number) {} to store the timeout value.

3

Implement the intercept method with timeout logic

Implement the intercept method with parameters context: ExecutionContext and next: CallHandler. Import Observable from rxjs and timeout operator from rxjs/operators. Return next.handle().pipe(timeout(this.timeout)).

NestJS

import { Injectable, NestInterceptor, ExecutionContext, CallHandler } from '@nestjs/common';
import { Observable } from 'rxjs';
import { timeout } from 'rxjs/operators';

@Injectable()
export class TimeoutInterceptor implements NestInterceptor {
  constructor(private readonly timeout: number) {}

  intercept(context: ExecutionContext, next: CallHandler): Observable {
    // Apply timeout operator to next.handle()
    // Your code here
  }
}

Hint

Use next.handle().pipe(timeout(this.timeout)) to apply the timeout.

4

Throw RequestTimeoutException on timeout

Import RequestTimeoutException from @nestjs/common. Modify the intercept method to catch timeout errors and throw RequestTimeoutException instead. Use catchError from rxjs/operators and throwError from rxjs.

NestJS

import { Injectable, NestInterceptor, ExecutionContext, CallHandler, RequestTimeoutException } from '@nestjs/common';
import { Observable, throwError } from 'rxjs';
import { timeout, catchError } from 'rxjs/operators';

@Injectable()
export class TimeoutInterceptor implements NestInterceptor {
  constructor(private readonly timeout: number) {}

  intercept(context: ExecutionContext, next: CallHandler): Observable {
    // Add catchError to throw RequestTimeoutException on timeout
    // Your code here
  }
}

Hint

Use catchError to check if the error is a timeout and throw RequestTimeoutException.

Practice

1.

What is the main purpose of a TimeoutInterceptor in a NestJS application?

easy

A. To stop requests that take too long and prevent hanging.

B. To log every request made to the server.

C. To cache responses for faster retrieval.

D. To authenticate users before processing requests.

Solution

1. Step 1: Understand the role of TimeoutInterceptor

   The TimeoutInterceptor is designed to limit how long a request can take before it is stopped.

2. Step 2: Compare options with the interceptor's purpose

   Only To stop requests that take too long and prevent hanging. describes stopping long requests to avoid hanging, which matches the interceptor's goal.

3. Final Answer:

   To stop requests that take too long and prevent hanging. -> Option A

4. Quick Check:

   TimeoutInterceptor stops long requests = D [OK]

Hint: TimeoutInterceptor stops slow requests to keep app responsive [OK]

Common Mistakes:

• Confusing timeout with logging or caching
• Thinking it handles authentication
• Assuming it speeds up all requests

2.

Which of the following is the correct way to apply a timeout of 5 seconds using RxJS timeout operator inside a NestJS interceptor?

return next.handle().pipe( ... )

easy

A. return next.handle().pipe(timeout(500));

B. return next.handle().pipe(timeout(5));

C. return next.handle().pipe(timeout(5000));

D. return next.handle().pipe(timeout(50));

Solution

1. Step 1: Understand RxJS timeout parameter

   The timeout operator expects time in milliseconds, so 5 seconds is 5000 ms.

2. Step 2: Match the correct timeout value

   Only return next.handle().pipe(timeout(5000)); uses 5000 which equals 5 seconds; others use incorrect values.

3. Final Answer:

   return next.handle().pipe(timeout(5000)); -> Option C

4. Quick Check:

   Timeout in ms for 5 seconds = 5000 [OK]

Hint: Timeout value is always in milliseconds in RxJS [OK]

Common Mistakes:

• Using seconds instead of milliseconds
• Using too small timeout values
• Forgetting to import timeout operator

3.

Given this TimeoutInterceptor code snippet, what will be the output if the request handler takes 7 seconds to respond?

intercept(context, next) {
  return next.handle().pipe(
    timeout(5000),
    catchError(err => throwError(() => new RequestTimeoutException()))
  );
}

medium

A. The request completes successfully after 7 seconds.

B. The request throws a RequestTimeoutException after 5 seconds.

C. The request throws a generic error immediately.

D. The request never completes or errors.

Solution

1. Step 1: Analyze timeout duration and handler delay

   The timeout is set to 5000 ms (5 seconds), but the handler takes 7 seconds, which is longer.

2. Step 2: Understand error handling on timeout

   When timeout triggers, catchError throws a RequestTimeoutException, so the request errors after 5 seconds.

3. Final Answer:

   The request throws a RequestTimeoutException after 5 seconds. -> Option B

4. Quick Check:

   Handler > timeout triggers RequestTimeoutException = A [OK]

Hint: Timeout triggers error if handler exceeds set milliseconds [OK]

Common Mistakes:

• Assuming request completes despite timeout
• Confusing generic error with RequestTimeoutException
• Ignoring catchError usage

4.

Identify the error in this TimeoutInterceptor implementation:

intercept(context, next) {
  return next.handle().pipe(
    timeout(3000),
    catchError(err => {
      throw new RequestTimeoutException();
    })
  );
}

medium

A. Using throw inside catchError instead of returning an observable error.

B. Timeout value should be in seconds, not milliseconds.

C. Missing import for RequestTimeoutException.

D. The interceptor must return a Promise, not an Observable.

Solution

1. Step 1: Check error handling inside catchError

   Inside catchError, throwing an error directly breaks the observable chain; it should return an observable error using throwError.

2. Step 2: Validate other options

   Timeout is correctly in milliseconds, imports are assumed correct, and interceptors return Observables, so only Using throw inside catchError instead of returning an observable error. is the error.

3. Final Answer:

   Using throw inside catchError instead of returning an observable error. -> Option A

4. Quick Check:

   Use throwError() inside catchError, not throw [OK]

Hint: Inside catchError, always return throwError() observable [OK]

Common Mistakes:

• Throwing error directly inside catchError
• Confusing milliseconds with seconds
• Assuming interceptors return Promises

5.

You want to create a TimeoutInterceptor that applies a 3-second timeout globally but allows a specific route to override it with a 10-second timeout. Which approach correctly implements this behavior?

hard

A. Set timeout to 10 seconds globally and manually check route inside interceptor to reduce to 3 seconds if needed.

B. Apply two TimeoutInterceptors globally, one with 3 seconds and one with 10 seconds; the last one wins.

C. Create two separate interceptors and apply the 10-second one only on the specific route without global interceptor.

D. Use a global TimeoutInterceptor with 3 seconds and a custom decorator to set metadata for 10 seconds, then read metadata inside the interceptor to override timeout.

Solution

1. Step 1: Understand global and route-specific timeout needs

   Global interceptor applies 3 seconds by default; specific routes can override by metadata.

2. Step 2: Implement override using custom decorator and metadata

   Custom decorator sets timeout metadata on route; interceptor reads it and uses that value if present.

3. Step 3: Evaluate other options

   Applying multiple global interceptors causes conflicts; setting longer timeout globally and reducing for most routes reverses the logic; creating separate interceptors without a global one loses timeout protection on other routes.

4. Final Answer:

   Use a global TimeoutInterceptor with 3 seconds and a custom decorator to set metadata for 10 seconds, then read metadata inside the interceptor to override timeout. -> Option D

5. Quick Check:

   Use metadata + decorator to override global timeout [OK]

Hint: Use custom decorator + metadata to override global interceptor timeout [OK]

Common Mistakes:

• Applying multiple global interceptors causing conflicts
• Hardcoding timeout values without metadata
• Not reading route metadata inside interceptor