Continuing from this earlier thread, GitHub issue #6489 and this follow-up thread – posting here after 21 days without a response, hoping to reach the Tyk team through the support Topics.
We’d like to get a review on PR #7813 from the Tyk team (it’s small, tested, and ready to merge).
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.