chore(opentelemetry-otlp): establish priority order for otlp clients #3280
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3280 +/- ##
=======================================
+ Coverage 80.7% 80.8% +0.1%
=======================================
Files 129 129
Lines 23210 23177 -33
=======================================
Hits 18748 18748
+ Misses 4462 4429 -33 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| // When multiple HTTP client features are enabled, we use a priority order | ||
| // to select the client. This follows Rust's feature unification principle | ||
| // where features should be additive. Priority (highest to lowest): | ||
| // 1. reqwest-client (async) |
There was a problem hiding this comment.
how is this priority decided? The default we use is the blocking-client (since the detail is the dedicated thread model..). But this order is reverse...
There was a problem hiding this comment.
My thinking is that when you explicitly turn on another client feature, that feature should win. Because blocking is the default feature if it appears first in the fallthrough here users wouldn’t be able to simply toggle on the feature, they’d have to also turn off default. As Leo points out in the issue this’d be counterintuitive. WDYT?
2 participants
Fixes #2994 using Paul's suggestion to implement a priority ordering for the HTTP clients when multiple are enabled.
Design discussion issue (if applicable) #
Changes
Please provide a brief description of the changes here.
Merge requirement checklist
CHANGELOG.mdfiles updated for non-trivial, user-facing changes