correlation_id is a framework-wide log field with no single definition. It is written as a string literal at six non-test sites, so nothing enforces the invariant that [C60.7] just documented — that on both messaging lanes correlation_id carries the framework trace ID and nothing else.
The six sites
messaging/internal/delivery/delivery.go — the shared outcome spine (AppendOutcome)messaging/registry.go:836 — logProcessingmessaging/registry.go:869, :885 — ackMessage, nackMessagescheduler/module.go:819server/logger.go:231
Why it is worth doing
The rename in #1068 exists precisely because two different ids were being stamped under one key on the same line. That class of collision is invisible to review as long as the key is a literal repeated across packages — and the atom that documents the invariant cannot be enforced by anything but prose.
There is a second, related asymmetry: correlation_id is the framework's own cross-service id (from X-Request-ID, else derived from a traceparent, else a minted UUID), while trace_id/span_id come from the OTel span and appear only when a tracer provider is registered. They hold different values by design, and no document says so.
Shape worth discussing
A logger-level shared vocabulary — exported field-name constants, or a small helper that stamps identity fields — so the key has one definition and the two identifier spaces are named in one place. Deliberately not scoped here; the right altitude is the open question.
Raised by an altitude reviewer during #1068 and deferred as out of scope for that PR.
correlation_idis a framework-wide log field with no single definition. It is written as a string literal at six non-test sites, so nothing enforces the invariant that [C60.7] just documented — that on both messaging lanescorrelation_idcarries the framework trace ID and nothing else.The six sites
messaging/internal/delivery/delivery.go— the shared outcome spine (AppendOutcome)messaging/registry.go:836—logProcessingmessaging/registry.go:869,:885—ackMessage,nackMessagescheduler/module.go:819server/logger.go:231Why it is worth doing
The rename in #1068 exists precisely because two different ids were being stamped under one key on the same line. That class of collision is invisible to review as long as the key is a literal repeated across packages — and the atom that documents the invariant cannot be enforced by anything but prose.
There is a second, related asymmetry:
correlation_idis the framework's own cross-service id (fromX-Request-ID, else derived from atraceparent, else a minted UUID), whiletrace_id/span_idcome from the OTel span and appear only when a tracer provider is registered. They hold different values by design, and no document says so.Shape worth discussing
A logger-level shared vocabulary — exported field-name constants, or a small helper that stamps identity fields — so the key has one definition and the two identifier spaces are named in one place. Deliberately not scoped here; the right altitude is the open question.
Raised by an altitude reviewer during #1068 and deferred as out of scope for that PR.