Warn when Sentry.init() options with semantic effect are passed as undefined
#14261
Assignees
Milestone
Comments
mydea
added a commit
that referenced
this issue
Nov 25, 2024
This PR updates & streamlines our handling of certain `undefined` options: First, we do not want to differentiate anymore between options being unset and set to `undefined` - the resulting behavior should be the same. This especially applies to the tracing options `tracesSampleRate`, `tracesSampler` and `enableTracing` - if any of those is set to `undefined`, `hasEnabledTracing()` will be true and certain things will happen. In v9, we want to change this so that `undefined` will also result in `hasEnabledTracing() === false`. We'll warn if we encounter such a scenario. Another related thing this PR does is streamline how we handle falsy values for `environment`, `release` and `dist` on an event. Today, we go out of our way to check if the properties are set and only update them accordingly. However, fasly values do not make sense for these fields anyhow, so we can streamline this a bit and simply check for truthiness to determine if we want to use event, option, or default values. Closes #14261
A PR closing this issue has just been released 🚀This issue was referenced by PR #14450, which was included in the 8.41.0 release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
As pre-work to #13262 where we want to change the behavior of
Sentry.init()options being passed asundefinednot having an effect, we want to first start warning people that this behavior will change soon.I would probably do this even when
debug: false. Remember that anyconsole.log()s need to be wrapped in a console sandbox.The text was updated successfully, but these errors were encountered: