Loading
fix: resolve one correlation id per request and use it everywhere
x-correlator is optional, and when a caller omitted it three separate pieces of
code each noticed the absence and invented their own answer: the service
generated one for the SRM request body, the SRM client sent no header at all,
and x_correlator_header generated a different one for the response. One request
produced two unrelated UUIDs and no downstream header.
The customer was handed an id that existed only in OEG's response header. It
was never sent anywhere, so quoting it to support matched nothing in SRM's
logs, and the id SRM did record was one the customer never saw. The correlation
id looked like a working feature and did nothing.
oeg/architecture.md is explicit that these are one value, and REQ-OEG-13
requires propagating it to downstream HTTP calls -- so this was a bug, not an
open question.
Resolve it once at the edge and read that everywhere: x_correlator_header
caches on request.state, get_caller_context takes the resolved value, and
routers pass caller.x_correlator. EAM already did this, so it was fixed by the
first two changes alone; QoD's get_qod_session had no caller parameter and
gains one.
LocationRetrievalService also sent the raw parameter as the SRM header while
building correlation_id for the body. Through the router those coincide, but a
direct call with None rebuilt the same divergence inside the service, and tests
and the conformance harness take that path.
test_passes_region_and_status_filters asserted x_correlator=None -- it encoded
the bug, so it is updated rather than preserved. The three new flow tests were
verified to fail when the wiring is reverted; a guard that cannot fail is not a
guard.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>