Ga naar inhoud

ADR-0019: FSC transaction ID as the end-to-end correlation key

Why superseded

If the two IDs are equal, the design breaks in three cases (F-67):

  • A caller sends its own traceparent.
  • One processing calls more than one source.
  • The request passes an extra FSC hop.

LDV and the ADL require that a component takes over the trace ID unchanged. FSC-Logging gives every transaction its own ID. Also, FSC forwards traceparent on the data path. Only the AuthZEN call from the Inway to the PDP drops it (F-41).

ADR-0035 makes W3C Trace Context the correlation key and records the transaction ID next to it. One part stays: an entry component without an incoming traceparent can tie its trace to the transaction ID that it mints. The following sections keep the original decision as history.

Context and problem statement

FSC does not propagate W3C trace context across the Inway. As a result, the trace of a consumer and the records on the provider side carry unrelated identifiers.

Decision (superseded)

Consumers generate a UUIDv7. They use it as the Fsc-Transaction-Id and also as the OpenTelemetry trace ID. The PDP records it in every decision log line. The FSC transaction logs of every hop carry it natively.

Consequences (at the time)

  • One identifier links the consumer request, the policy decision, and the audit record of each hop. A deny reason can be traced to the exact exchange.
  • Debug stores (Jaeger, Loki) keep data only for a short time. The FSC txlog stays the authoritative record. For more information, see Logging and traceability.
  • If a later FSC version supports trace-context propagation, GBO can change this convention without breaking the txlog linkage.

Traceability

  • Requirements: REQ-55
  • Findings: F-39 (resolved in demo), F-41 (resolved in demo), F-67 (resolved in demo)
  • Open questions: none
  • Demo increments: SL-07 (done), SL-38 (done)