Request IDs and Structured Logging

Request IDs & Structured Logging Use Fastify request IDs, response headers, timing, and NestJS 12 structured logger metadata

Phase 13 - Professional Error Handling Volume 04 - Professional Backend

Architecture milestone Fastify request.id

↓

interceptor

↓

x-request-id + success log

↓

exception filter for failures

Phase 13 creates one professional exception boundary and a correlation story that spans client response and server logs.

Fastify already gives every request an ID Fastify Request includes an id field. We can reuse it as the TaskFlow correlation identifier instead of inventing a separate request-context system during this phase.

import { CallHandler, ExecutionContext, Injectable, Logger, NestInterceptor, } from "@nestjs/common"; import { FastifyReply, FastifyRequest } from "fastify"; import { Observable } from "rxjs"; import { tap } from "rxjs/operators";

@Injectable()
export class RequestLoggingInterceptor implements NestInterceptor {
private readonly logger = new Logger(RequestLoggingInterceptor.name);

intercept(
context: ExecutionContext,
next: CallHandler,
): Observable<unknown> {
const http = context.switchToHttp();
const request = http.getRequest<FastifyRequest>();
const reply = http.getResponse<FastifyReply>();
const requestId = String(request.id);
const startedAt = performance.now();

reply.header("x-request-id", requestId);

return next.handle().pipe( tap(() => { this.logger.log("Request completed", { requestId, method: request.method, path: request.url, statusCode: reply.statusCode, durationMs: Math.round(performance.now() - startedAt), }); }), ); } }

What the interceptor owns • Read Fastify request.id.

• Return the same identifier in the x-request-id response header for successful responses.

• Measure request duration.

• Write one structured completion log after successful controller execution.

• Avoid swallowing exceptions; failures continue to the global exception filter.

Do not blindly trust caller-provided request IDs

Fastify can be configured to use an incoming request-id header, but its documentation warns that callers can then choose arbitrary values unless you validate them. TaskFlow keeps Fastify-generated IDs for now.

NestJS 12 structured logger metadata NestJS 12 treats plain objects passed after the message as structured parameters. That makes metadata such as requestId, method, path, durationMs, and statusCode easy to keep together in one log record.

this.logger.log("Request completed", { requestId, method: request.method, path: request.url, statusCode: reply.statusCode, durationMs, });

Success and failure logs have different owners The interceptor logs successful completion. The exception filter logs rejected requests and unexpected faults because it knows the final error classification and public status code. This avoids duplicate error logs for the same exception.

Figure 1 - Logging split Successful request

↓

RequestLoggingInterceptor logs completion

↓

Error request

↓

ApiExceptionFilter logs rejection/fault

One event per responsibility keeps logs readable.