[opentelemetry-php-contrib] Add some way to reset/create new TracerProvider in Symfony Bundle

[DrLuke]

Is your feature request related to a problem? I have a long running process in symfony processing messages from a queue, so the kernel isn't restarted between traces. Currently it is impossible to start a fresh trace for each handled message unless you manually recreate and overwrite the TracerProvider in the container.

Describe the solution you'd like Symfony has a mechanism to reset services tagged as resettable. Maybe it could be possible to create a ResettableTracerProvider that can then be tagged appropriately.

[tidal]

@DrLuke Thanks for the feature request!

This is super valuable feedback and in general, if you have any feature requests regarding the Bundle or maim library, please request away! :)

However this points more to a lack in documenation/examples from our side, and it's not really intuitive how to create a new trace in the same process. The TraceProvider is part of the Otel specification, which is also implemented in languages which are executed in long running processes as a default. Or in other words, you don't need to create a new TracerProvider to create a new trace, as the trace state is not hold in the TracerProvider directly but in the Context.

I have created ~~a PR with~~ an example of how to create a new trace in the same process, however this is the gist of it:

// 'activate' is returning a reference to the context scope
$rootScope = $rootSpan->activate();
//  This is detaching the root span's contect, and thus the next created span will belong to a new trace.
$rootScope->detach();

However, I want to keep your feature request open, as I think adding a reset tag in the Symfony Bundle or in fact adding the possibilty to add any kind of (custom) tag to a Otel componentwould would be a nice feature in general.

[DrLuke]

Thank you so much for the detailed explanation and the example!

[DrLuke]

@tidal

I've been struggling with this for the past couple days because I kept getting the same TraceId even though I detached the root span (and all activated child spans, detaching the root span returns 0) as in your example. I noticed that when the context storage is first initialized, there is always a root context that is created. Thus even the first span I create and activate will already be a child context and inherit the TraceId if I understood correctly?

I'm stuck here now, so any insight would be greatly appreciated!

[DrLuke]

Oops, the issue was that I activated the root span twice on accident, but only detached once. Thus the first root span remained in storage and each new span would inherit the TraceId from that.

[tidal]

Oops, the issue was that I activated the root span twice on accident, but only detached once. Thus the first root span remained in storage and each new span would inherit the TraceId from that.

Hmm, that still seems like quite unintuitive behavior, if not like a bug.

I will take a look, if I have time.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[brettmc]

that still seems like quite unintuitive behavior, if not like a bug

I don't think there is anything we can do code-wise about accidentally starting duplicate root spans, because it's also a legit use-case. I see how it's problematic in a long-running process though. On shutdown I think we'd complain about scope not detached, but that doesn't help here.