It turns out there was a flaw in that logic for choosing the span to propagate. Instead of using the current span as managed by the tracing implementation the code used whatever span, if any, that was already set in the current Helidon Context and actually ignored the tracing implementation's notion of the currently-active span.
The key change here is that the propagation logic uses the span from the tracing implementation's current span only.
Any span that might already be set in the current context at the time propagation is being prepared is immaterial. For example, in the time since the span was set in that context some user code might have closed the scope which had made that span the current one, meaning no span was current. Or user code could have made some other span the current span in the meantime.
The PR also contains a slight adaptation of a user test that had exposed this problem in the first place (see the attachment to the issue). The new test is in provider-tests so all provider implementations by default need to pass it. The test is written using the Helidon neutral tracing API. Because our Zipkin provider implementation does not implement the Helidon tracing API, this PR modifies the Zipkin build to exclude the new test. A separate issue will capture the possible change for Zipkin to implement the Helidon neutral tracing API at which point the new test from this PR should no longer be excluded from the Zipkin build.
Backport of #8841 to 4.0.10
Description
Resolves #8824
The earlier PR https://github.com/helidon-io/helidon/pull/8742 added propagation of tracer information for the OTel provider that was patterned after the long-standing Jaeger propagation.
It turns out there was a flaw in that logic for choosing the span to propagate. Instead of using the current span as managed by the tracing implementation the code used whatever span, if any, that was already set in the current Helidon Context and actually ignored the tracing implementation's notion of the currently-active span.
The key change here is that the propagation logic uses the span from the tracing implementation's current span only.
Any span that might already be set in the current context at the time propagation is being prepared is immaterial. For example, in the time since the span was set in that context some user code might have closed the scope which had made that span the current one, meaning no span was current. Or user code could have made some other span the current span in the meantime.
The PR also contains a slight adaptation of a user test that had exposed this problem in the first place (see the attachment to the issue). The new test is in provider-tests so all provider implementations by default need to pass it. The test is written using the Helidon neutral tracing API. Because our Zipkin provider implementation does not implement the Helidon tracing API, this PR modifies the Zipkin build to exclude the new test. A separate issue will capture the possible change for Zipkin to implement the Helidon neutral tracing API at which point the new test from this PR should no longer be excluded from the Zipkin build.
Documentation
No impact