-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add options to disable timer and event target instrumentation #938
Add options to disable timer and event target instrumentation #938
Conversation
LGTM 👍 |
I don't want to have 3 (or more) Raven.config('your-dsn', {
instrument: {
timers: false,
eventTargets: false,
http: false // XMLHttpRequest/fetch - better name welcome
}
}); ... kind of like how we've done with |
That makes sense @benvinegar! I'll send PR with this change shortly |
@benvinegar - It seems like xhr (or http as you put it in example) instrumentation config lives on |
It still instruments with try/catch (or at least, it should). You don't have to implement the option: I just want the API to have a place to expand to when we introduce it in the future. |
@benvinegar - updated, let me now if that works for you! edit: awkward wording, I did actually test it :P I meant if the change is OK for you |
Looks p good, I think last thing is I'd add an integration test that verifies the built-ins haven't been overridden. Our integration tests are pretty wacky, so I don't mind putting that part together. |
@benvinegar - would be great if you could -- I'd like to get this landed as soon as possible so Expo users can use Sentry easily so if it will take you some time I can dig into it |
ping @benvinegar :) |
Hey, I'll try to investigate this tomorrow. |
happy monday @benvinegar! |
|
Looks like editing the integration tests is too tricky because you can't set a If you could quickly add some cursory tests that verify the |
cool, thanks! done |
I guess the last thing is: doing
Should we re-evaluate this assertion? |
Is this something we could discuss in the Expo slack channel? |
@benvinegar - yeah let's do that |
0772c5a
to
fd85919
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation needs some expanding but I can do this asynchronously.
@LewisJEllis @MaxBittker – could one of you publish 3.15.0? |
Published 3.15.0, see #955. |
🎸 |
Within react-native, it doesn't make sense for us to instrument timers because they are already wrapped in try/catch and their errors are reported to ErrorUtils. Additionally, if we don't disable the timer instrumentation then the error will be handled separately by ErrorUtils and the try/catch wrapper. This lead to, in my case, fatal errors being reported immediately (rather than on next load) and not having the correct metadata on Android because I wasn't able to modify the stack before passing it through TraceKit.
As for event targets, it doesn't seem necessary within the React Native context where these mostly don't exist -- I imagine people would want this off by default in RN.
See the related PR to react-native-sentry: getsentry/sentry-react-native#40