What is ExecutionContext in NestJS and why is it central to guards, interceptors, and filters?
ExecutionContext extends ArgumentsHost and provides metadata about the current execution — the transport type (HTTP, WebSocket, RPC) and which handler and class will process it. Its getHandler() and getClass() methods are used with Reflector to read @SetMetadata() values for RBAC and feature flags.
- 1
getHandler() and getClass() give guards and interceptors access to the matched route metadata.
- 2
switchToHttp(), switchToWs(), switchToRpc() make enhancers transport-agnostic.
- 3
Used by Reflector to read @SetMetadata() values — essential for RBAC, @Public(), feature flags.
- 4
ArgumentsHost (parent interface) is used by exception filters; ExecutionContext extends it with handler/class info.
Scenario Questions
0-2 years experience
- 1If you need to check a user's role inside a guard, how would you retrieve the request object using ExecutionContext?
- 2What would happen if you called context.switchToHttp().getResponse() inside a GraphQL resolver guard? Explain why.
2-5 years experience
- 1You added a custom interceptor that logs execution time, but the logged time is always zero for certain routes. How would you use ExecutionContext to debug this issue?
- 2During a migration from REST to GraphQL, a filter that relies on context.getType() started throwing errors. Walk me through how you'd adjust the filter using ExecutionContext to handle both protocols.
5-8 years experience
- 1In a high‑traffic microservice, you need to share a per‑request correlation ID across guards, interceptors, and exception filters without passing it manually. How would you design this using ExecutionContext and what trade‑offs should you consider?
- 2Your team wants to implement role‑based access control that works for both HTTP and WebSocket gateways. Explain how ExecutionContext helps you abstract the underlying request objects and what performance implications might arise.
8+ years experience
- 1We are consolidating several legacy NestJS modules into a monorepo. Some modules use custom guards that directly access request.user, while others use interceptors to inject metadata. How would you refactor the codebase to standardize on ExecutionContext usage, and what architectural guidelines would you set to avoid future inconsistencies?
- 2Imagine a cross‑team initiative to add observability (tracing, metrics) across all NestJS entry points. Design a strategy that leverages ExecutionContext in a global interceptor, and discuss how you'd ensure compatibility with existing custom guards and filters without degrading latency.
Follow-up Questions
- Can you give an example of extracting a custom header using ExecutionContext?
- How would you mock ExecutionContext in unit tests for a guard?
- What limitations have you seen when using ExecutionContext with custom decorators?