Continuing from this earlier thread and GitHub issue #6489.
The problem: when OpenTelemetry is enabled on the Tyk gateway, gRPC coprocess plugins (and other out-of-process plugins like Python) have no access to the active trace context. Any spans created inside the plugin start a brand-new disconnected trace instead of being a child of the gateway’s trace — breaking end-to-end distributed tracing.
What we built: a minimal fix in PR #7813. The gateway injects the active span’s propagation headers into Object.Metadata when dispatching to the plugin, using the same global propagator already configured via context_propagation (W3C tracecontext or B3). No protobuf changes, no interface changes, fully backward compatible.
Plugins read the headers via the existing metadata map:
- Java:
object.getMetadataMap().get("traceparent") - Python:
object.metadata["traceparent"]
Tested end-to-end against a real Java gRPC plugin — traceparent appears in the plugin logs on every request, with the correct trace ID matching the gateway’s span.
We’d love a review on PR #7813 from the Tyk team — it’s small, tested, and ready to merge.