-
-
Notifications
You must be signed in to change notification settings - Fork 485
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naming Conventions for Propagating Traces #2200
Comments
Let me see if I understand this correctly:
It looks like we should add the new option, and soft-deprecate the old one. Another gotcha: we should prepare and ship the documentation change at the same time. How far off am I? If my understanding is more or less alright, I'm happy to put this together. /cc @sl0thentr0py |
we already have sentry-ruby/sentry-ruby/lib/sentry/configuration.rb Lines 272 to 275 in c588979
https://docs.sentry.io/platforms/ruby/usage/distributed-tracing/limiting-trace-propagation/ ruby was the only SDK that had sentry-ruby/sentry-ruby/lib/sentry/net/http.rb Lines 99 to 100 in c588979
if you really want we can deprecate and remove the boolean, but not really necessary. |
I added missing docs |
Describe the idea
We have controls in SDKs to influence to what endpoints tracing headers should be propagated. This allows users to control what is being traced, where data is being sent. This is because not all endpoints are functionally relevant for users to trace (3rd parties) and sometimes they just don't want to have distributed tracing.
Today ruby has this option documented, config.propagate_traces. While in JS for example there is tracePropagationTarget
These play a similar role but do different things, boolean vs array of regexes, ruby BE and JS FE. Should we have the same naming convention in Ruby as others?
Why do you think it's beneficial to most of the users
This is really just a naming convention thing, to have it same or similar across SDKs
Possible implementation
Python has trace_propagation_targets as optional, and is probably a better model for how Ruby should behave.
The text was updated successfully, but these errors were encountered: