Jaeger overflow error from OrderedFloat

[Dustin-Ray]

Describe the bug
There is a conflict arising from multiple versions of the opentelemetry crate being pulled into the same dependency graph, causing the compiler to see traits (like Tracer) as coming from different crates. Despite explicitly aligning dependencies (e.g., opentelemetry, opentelemetry-jaeger, and tracing-opentelemetry) to the same version, transitive dependencies still bring in older or newer opentelemetry versions. This leads to errors such as “the trait comes from a different crate version,” as well as a nested “overflow evaluating the requirement” involving ordered_float and thrift. The issue persists when building or testing, resulting in compilation failures and Clippy checks that cannot complete successfully.

To Reproduce

Below is a minimal project setup demonstrating the issue. Attempting to build this project will produce errors related to multiple versions of the opentelemetry crate.

Place the following code in any testing module (This behavior was originally reserved in the range check test plan)

  init_backend();

  use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt, EnvFilter};

  let tracer = opentelemetry_jaeger::new_agent_pipeline()
      .with_service_name("benches")
      .install_simple()
      .unwrap();

  let opentelemetry = tracing_opentelemetry::layer().with_tracer(tracer);

  let filter = EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new("DEBUG"));

  tracing_subscriber::registry()
      .with(opentelemetry)
      .with(filter)
      .try_init()
      .unwrap();

(Note this may or may not work, the behavior is very inconsistent.)

Expected behavior
After aligning the opentelemetry dependencies to a single version, we expect the project to compile successfully without trait-version conflicts. The Jaeger tracer should install cleanly, allowing spans to be emitted through tracing-opentelemetry or any other instrumentation layer, with no errors related to multiple opentelemetry crates in the dependency graph.

Additional context

• This conflict often arises when multiple crates (like opentelemetry-jaeger and tracing-opentelemetry) have different semver ranges for opentelemetry, pulling in mismatched versions (e.g., 0.21.x and 0.22.x).
• The issue can manifest as both trait-incompatibility errors (the trait comes from a different crate version) and infinite nesting errors for crates like ordered-float, especially if thrift is involved.
• Workarounds might? involve consolidating all crates on the same version of opentelemetry (this failed in my attempts so far) (and possibly thrift), or using the HTTP transport instead of Thrift to avoid older ordered-float. (havent tried this yet)

[JayWhite2357]

It appears that opentelemetry-jaeger is deprecated. I imagine that removing the use of this would fix the issue.