Fix integration tracers initializing too early #756
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When configuring Datadog with OpenTracing, typically the
Datadog.tracer
gets swapped for the OpenTracing instance ofDatadog::Tracer
.Given the original code for defining a
tracer
option for integrations, it was initializing its own reference toDatadog::Tracer
at load time, instead of at run time. This means when OpenTracing was configured, the integrations were using the old instance created at load time, and a 2nd tracer was being used just for OpenTracing. This could manifest some strange behavior, and cause the Datadog tracer to appear misconfigured.The interim solution is to lazy initialize
tracer
for integrations. It's only a short term fix though, given if you reassign the Datadog global tracer after configuring the integrations, you'll end up with the same issue. Thus with this change its recommended that integrations are only configured after the global tracer has been. e.g.