Skip to main content

Request Tracing

In a production system, you need to trace a request from entry to response — especially when debugging errors or diagnosing latency. PrismTracingMiddleware assigns unique IDs to every request and propagates correlation IDs across service boundaries.

Quick Setup

Enable Tracing
Every response now includes X-Request-ID. If the client sends one, it’s preserved; otherwise, a new UUID is generated.

How It Works

  1. Incoming request checked for X-Request-ID header
  2. If missing and generateIfMissing is true, a UUID is generated
  3. X-Correlation-ID and X-Parent-ID headers are captured if present
  4. All IDs stored in request.userInfo for downstream handlers
  5. Response includes X-Request-ID and X-Correlation-ID headers

Configuration

Custom Headers

Accessing Trace Context

Use in Handlers
The PrismTraceContext provides:
  • requestID — unique ID for this request
  • correlationID — groups related requests across services
  • parentID — the upstream request that triggered this one
  • startTime — when the trace was created
  • elapsed — time since the trace started

Structured Logging

PrismTracingLogger formats log messages with trace context:
Traced Logging

Cross-Service Tracing

When calling other services, forward the trace headers:
Propagate to Downstream

Custom Logger

Logger without Context
Always forward correlation IDs to downstream services. When debugging a production issue, you can search logs across all services using the correlation ID to see the complete request flow.
The request ID is stored in request.userInfo["traceContext.requestID"]. If you’re accessing it from raw userInfo, remember that the key includes the traceContext. prefix.