# Request IDs and trace context across gateway, API and engine

Separate generation IDs, internal request IDs and trace/span IDs through uniqueness scopes, propagation, safe correlation and missing-context fixtures.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/provider-request-id-trace-context/
Language: en

A client sees one generation ID, the API records another request ID, and the engine uses a local identifier. Without mappings, investigation becomes timestamp guessing. Providers benefit from a correlation map preserving each identifier's scope and connecting logical operations with attempts. It should support diagnosis without placing user content into every technical channel.

## Name distinct identities

[OpenTelemetry context propagation](https://opentelemetry.io/docs/concepts/context-propagation/) describes distributed-operation context. Trace and span IDs belong to that observation model, while request IDs can exist independently. Matching strings do not make them the same concept or guarantee equal lifetimes.

Record value source, uniqueness scope and storage. An engine ID may be unique only inside one process. An external generation ID belongs to a platform interface. Substituting them in error reports can destroy links after restarts or retries.

## Check external identifiers

The [OpenRouter streaming reference](https://openrouter.ai/docs/api_reference/streaming) documents X-Generation-Id for correlation on its endpoints. That is useful external evidence rather than a mandatory header for every upstream. An owned service should document accepted and returned identifiers separately.

Define trust policy for client-provided identifiers. They may repeat, be absent or malformed. Server records must not merge unrelated operations because the same string arrived. Use short synthetic identifiers without secrets in fixtures.

## Link attempts with operations

One logical operation may contain several transport attempts. Preserve parent relationships and individual outcomes. Fallback to another replica does not necessarily create a new user task, but performed work should not disappear from diagnosis either.

A correlation map can contain safe IDs, endpoint, release and outcome without full prompts. Timestamp matching remains secondary; it does not ensure exact association under concurrency or across unsynchronized host clocks.

## Bound propagated data

The [OpenTelemetry sensitive-data guide](https://opentelemetry.io/docs/security/handling-sensitive-data/) covers minimization and filtering. Baggage and headers must not become hidden containers for access tokens, personal addresses or request content. Propagation does not authorize sending arbitrary metadata onward.

Define an allowlist and removal points. Put a clearly synthetic sensitive marker into a fixture, then inspect actual exported payloads. Successful application responses do not establish that filters worked on error paths or in extra logging middleware.

## Test missing context

Exercise absent external IDs, malformed trace context and repeated client IDs. Expected behavior should retain a diagnosable operation without trusting unsupported identity claims. Save results with instrumentation version and propagation settings.

Related guides cover [useful failure reports](/journal/openrouter-500-error/) and [GPU monitoring](/journal/gpu-monitoring-scorecard/). The artifact is a verified link between technical events, not a promise of complete tracing across external services or a requirement to disclose user content. Retain the mapping policy as well as example IDs, because later changes in retry handling can create multiple attempts that share a client identifier while requiring distinct internal records.