TraceableHttpClientForV6 twice in symfony/http-client decoration chain

[simonberger]

Versions:

• sentry-symfony: 4.6.0
• symfony/http-client: 5.4

I noticed some strange decoration behavior of the http-client when scoped clients are used and Symfonys TraceableHttpClient is not used (no debug/webprofiler). I end up in the following HttpClient (decoration) chain:

• TraceableHttpClientForV6
• ScopingHttpClient
• TraceableHttpClientForV6
• CurlHttpClient

This caused an unexpected side effect for us, as we are decorating the http-client as well (bug reproduced without our decoration as shown in the chain).
Beside the performance impact, the second client receives the sentry-trace header already in the normalized way by the ScopingHttpClient `[0 => 'sentry-trace: xyz'] and adds it again, ending in a mixed array with doubled header.

[
   0 => 'sentry-trace: xyz'
   'sentry-trace' => 'xyz'
]

The CurlHttpClient most likely resolves this correctly again in the next normalization iteration happening there and we did it on our side now as well, but still this needs improvement. Ideally for sure getting rid of the decorator after the ScopingHttpClient.

If symfonys tracing is active the chain is intact:

• TraceableHttpClientForV6
• TraceableHttpClient
• ScopingHttpClient
• CurlHttpClient

[cleptric]

Ohhh, fun 😕
I'll take a look, if you have any ideas in the meantime, happy to review a PR.

[simonberger]

I debugged the Sentry decoration a bit, but got no real idea where the problem lies or how to change it.

[simonberger]

@cleptric I was curious if a test is possible and it was. I hope you can run it as well
#701

[cleptric]

Thanks a lot, this is super helpful 🚀