Skip to content

Conversation

jerrytfleung
Copy link
Contributor

@jerrytfleung jerrytfleung commented Sep 9, 2025

Issue

Currently there are 2 response propagators (ServerTimingPropagator & TraceResponsePropagator) in otel-php to propagate information to response. However, they are called explicitly in different instrumentations (e.g. Slim, Symfony, etc). As a result, vendors are unable to propagate their specific information to response.

Proposal

With the ongoing otel spec PR (1355, 3825) and they are still under review, I am proposing an experimental response propagator interface so as to allow vendor to propagate their specific response.
Once this PR is in, both ServerTimingPropagator and TraceResponsePropagator can implement the same ResponsePropagatorInterface and the following code in the instrumentation library could be replaced

// Propagate server-timing header to response, if ServerTimingPropagator is present
if (class_exists('OpenTelemetry\Contrib\Propagation\ServerTiming\ServerTimingPropagator')) {
    $prop = new \OpenTelemetry\Contrib\Propagation\ServerTiming\ServerTimingPropagator();
    $prop->inject($response, ResponsePropagationSetter::instance(), $scope->context());
}
// Propagate traceresponse header to response, if TraceResponsePropagator is present
if (class_exists('OpenTelemetry\Contrib\Propagation\TraceResponse\TraceResponsePropagator')) {
    $prop = new \OpenTelemetry\Contrib\Propagation\TraceResponse\TraceResponsePropagator();
    $prop->inject($response, ResponsePropagationSetter::instance(), $scope->context());
}

by

$prop = Globals::responsePropagator();
$prop->inject($response, ResponsePropagationSetter::instance(), $scope->context());

@jerrytfleung jerrytfleung requested a review from a team as a code owner September 9, 2025 18:40
Copy link

welcome bot commented Sep 9, 2025

Thanks for opening your first pull request! If you haven't yet signed our Contributor License Agreement (CLA), then please do so that we can accept your contribution. A link should appear shortly in this PR if you have not already signed one.

Copy link

codecov bot commented Sep 9, 2025

Codecov Report

❌ Patch coverage is 48.78049% with 63 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.10%. Comparing base (2f3e214) to head (e9e72fb).
⚠️ Report is 4 commits behind head on main.

Files with missing lines Patch % Lines
.../Config/SDK/ComponentProvider/OpenTelemetrySdk.php 0.00% 31 Missing ⚠️
...rovider/Propagator/ResponsePropagatorComposite.php 0.00% 7 Missing ⚠️
.../SDK/Propagation/LateBindingResponsePropagator.php 0.00% 6 Missing ⚠️
src/SDK/Propagation/ResponsePropagatorFactory.php 64.70% 6 Missing ⚠️
src/SDK/Registry.php 37.50% 5 Missing ⚠️
src/SDK/Propagation/_register.php 0.00% 4 Missing ⚠️
src/SDK/SdkAutoloader.php 75.00% 3 Missing ⚠️
src/Context/Propagation/NoopResponsePropagator.php 83.33% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff              @@
##               main    #1712      +/-   ##
============================================
- Coverage     68.37%   68.10%   -0.28%     
- Complexity     2878     2919      +41     
============================================
  Files           430      435       +5     
  Lines          8757     8876     +119     
============================================
+ Hits           5988     6045      +57     
- Misses         2769     2831      +62     
Flag Coverage Δ
8.1 67.83% <48.78%> (-0.31%) ⬇️
8.2 68.03% <48.78%> (-0.30%) ⬇️
8.3 68.07% <48.78%> (-0.27%) ⬇️
8.4 68.01% <48.78%> (-0.32%) ⬇️
8.5 68.07% <48.78%> (-0.26%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
src/API/Globals.php 100.00% <100.00%> (ø)
...PI/Instrumentation/AutoInstrumentation/Context.php 100.00% <ø> (ø)
src/API/Instrumentation/Configurator.php 100.00% <100.00%> (ø)
src/API/Instrumentation/ContextKeys.php 100.00% <100.00%> (ø)
src/API/Instrumentation/InstrumentationTrait.php 95.91% <100.00%> (+0.46%) ⬆️
...rc/Context/Propagation/MultiResponsePropagator.php 100.00% <100.00%> (ø)
src/SDK/Sdk.php 100.00% <100.00%> (ø)
src/SDK/SdkBuilder.php 100.00% <100.00%> (ø)
src/Context/Propagation/NoopResponsePropagator.php 83.33% <83.33%> (ø)
src/SDK/SdkAutoloader.php 91.97% <75.00%> (-1.73%) ⬇️
... and 6 more

... and 3 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2f3e214...e9e72fb. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@brettmc
Copy link
Contributor

brettmc commented Sep 9, 2025

This looks pretty sensible. Can you add an example of how it's used?
I think it would be more ergonomic if the response propagator was obtained from Globals like other propagators are. That's an API change, but it's a php-specific part of the API that's not strictly defined in spec.
I think it would be worth linking to the relevant issues/PRs from code, for future reference.

$sdkBuilder->setPropagator($propagator);

$responsePropagators = [];
foreach ($properties['response_propagator']['composite'] as $plugin) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. I agree that ideally this is how it would work, and the config spec allows extra entries here, but I think we should be cautious about adding non-spec entries here. At the least, it should be experimental_response_propagator. My main concern is incompatibility if/when something is added to spec.
The config repo may accept a PR adding it as experimental and optional?

Copy link
Contributor Author

@jerrytfleung jerrytfleung Sep 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Changed to use response_propagator/development

@brettmc
Copy link
Contributor

brettmc commented Sep 11, 2025

This looks pretty good. Most of my review comments are about not over-committing or doing things that might conflict with future spec changes. We need to be cautious while moving ahead of the spec.

@jerrytfleung
Copy link
Contributor Author

jerrytfleung commented Sep 11, 2025

This looks pretty good. Most of my review comments are about not over-committing or doing things that might conflict with future spec changes. We need to be cautious while moving ahead of the spec.

Yes, it is quite a lot of files change if adding the interface to Globals. While changing the config from response_propagator to response_propagator/development and using OTEL_EXPERIMENTAL_RESPONSE_PROPAGATORS, I think we could adapt to the future spec changes.

Copy link
Contributor

@brettmc brettmc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good to go - just one minor tidy up thing please

@brettmc brettmc merged commit 00417cf into open-telemetry:main Sep 19, 2025
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants