- What does open-telemetry/opentelemetry-propagation-traceresponse do?
- It is an OpenTelemetry PHP propagator for the draft traceresponse HTTP header. It implements TextMapPropagator inject and extract flows so services can write trace context into responses and read it when present. It complements W3C tracecontext and baggage propagation rather than replacing them. It is not a tracer, exporter, or instrumentation library.
- How do I install open-telemetry/opentelemetry-propagation-traceresponse with Composer?
- Install it with composer require open-telemetry/opentelemetry-propagation-traceresponse. It targets PHP 8.x and opentelemetry-api 1.x, consistent with the rest of the OpenTelemetry PHP stack. There is no Laravel service provider or config publish step, so wiring is manual. Because the contrib package is marked READONLY, pin an exact version and treat it as provisional.
- How do I enable traceresponse propagation in Laravel?
- Register the propagator in the OpenTelemetry propagator chain, for example OTEL_PROPAGATORS=tracecontext,baggage,traceresponse or the equivalent SDK builder configuration. Then add Laravel response-side plumbing so traceresponse is injected into responses returned to the caller. Auto-instrumentation typically handles outbound HTTP calls, not the response header sent back to clients. Review middleware order, especially for error, abort, fallback, and streaming responses.
- Does this package support Laravel 10 or Laravel 11?
- The package has no Laravel framework coupling, so compatibility depends on your PHP and OpenTelemetry PHP SDK versions rather than the Laravel version itself. Laravel applications on PHP 8.x with opentelemetry-api 1.x are the intended fit. It does not ship a Laravel service provider, so you register it yourself in the propagator chain. Check the package Composer constraints before upgrading Laravel or the OTel SDK.
- Why is the traceresponse header missing from my Laravel responses?
- OpenTelemetry auto-instrumentation usually propagates context on outbound HTTP calls, while traceresponse must be injected into the response returned to the caller. You generally need kernel-level middleware to add the header, including on abort(), exception handler, early-return, and streaming paths. Also verify that CORS exposes the header to browsers and that CDNs, reverse proxies, or gateways are not stripping it. Under Octane, confirm middleware ordering and long-lived worker behavior.
- Is traceresponse a standardized header I can rely on in production?
- traceresponse is a draft header in the W3C distributed-tracing orbit, not a ratified standard, so its name, encoding, and semantics can change. The package lives in a READONLY contrib repository, which is a signal that it is frozen rather than actively evolving. Treat adoption as reversible and put it behind a feature flag where possible. Pin the dependency and keep the exit path to a configuration change.
- Should I use traceresponse alongside traceparent and baggage?
- Yes, the recommended chain is tracecontext,baggage,traceresponse so standard W3C context and baggage continue to work. traceresponse overlaps semantically with traceparent, so running both increases the context surface on every response. Only add traceresponse when a named consumer such as a browser RUM agent, partner API, or internal client SDK actually reads it. Without a consuming party, it is header decoration with no correlating counterpart.
- How can I test that traceresponse propagation works in my application?
- Send a request through the Laravel application and inspect the response header to confirm trace context is present. Test extraction with absent and malformed traceresponse headers to ensure the propagator never throws into the request lifecycle. Cover error handlers, abort(), Route::fallback, streaming responses, and Octane worker behavior. An integration test that asserts middleware ordering is more valuable than a unit test of the propagator alone.
- Will browsers or CDNs see the traceresponse response header?
- Browser JavaScript will not see a custom response header unless Access-Control-Expose-Headers includes traceresponse. CDNs, reverse proxies, WAFs, and API gateways may strip, cache, or reject unknown response headers. Verify the header survives end to end at your edge before relying on it for correlation. If a downstream consumer cannot receive it, the propagation provides no operational value.
- What are the alternatives or maintenance concerns for this package?
- The main alternative is standard W3C tracecontext via traceparent, plus baggage or vendor-specific correlation IDs. This package is frozen in a contrib repository with very low adoption signals, so there is little community evidence of production use. Check the consolidated OpenTelemetry PHP contrib repository for a documented successor package or migration note. Keep the integration isolated so replacing it is one config line rather than a client contract change.