I am using RNsentry on android (version 0.12.12, I just upgraded to the latest 0.14.0), and I am wondering how “long” the data provided in Sentry.setExtraContext(), Sentry.setTagsContext() and such remains in the Sentry object.
Specifically, I import the Sentry object in my index.android.js and call Sentry.config() and the above functions with info from code-push (that works well, if I captureMessage() at this point, the info gets through).
But later in the app (in another file), I import the same Sentry again (from react-native-sentry as well) and send a message to sentry, but the tags and context have now disappeared.
Why is this happening? and how do I make sure the info I pass to Sentry/raven “persists” (the above events are only a few seconds apart, no sending the app to sleep or background or anything).
I am receiving the same bug. I have attempted to set multiple context and username related Sentry items on the Sentry object, but it does not appear to persist between component calls or navigation routes. Is the Sentry object something that should be put in a redux store and passed around in order to keep it in the same scope throughout the application?
Edit: I recently verified that this issue does not extend to iOS. I am capable of updating the Sentry object using setExtraContext() from multiple points in the code and have that context sent up via captureMessage() calls from other code locations.
Here is what my code looks like, I don’t think it calls multiple times (console outputs messages only once):
codePush.getUpdateMetadata().then((update) => {
// gather data for sentry client...
Sentry.config("....", {...}).install();
console.log('this is only printed once');
});
in index.android.js just before AppRegistry.registerComponent().
It does run every time the app starts, but I guess that is the expected behaviour?
I guess you could say I have a slightly different problem than OP, as I am only calling my config / install at the index of my application. However, I cannot seem to get the Sentry.setTagsContext() to push any data up to my Sentry stream.
I have been attempting to duplicate the configuration found at this link but “environment” does not seem to be a tag that I can hook into.
Do you know of a better list of tags that I can use?
I had put the call to install in the callback so I would have access to the codepush version info, but I tried to move it outside to the main part of index.android.js and that seems to have mostly fixed the problem.
Except for setVersion() which disappears at some point.
Here is the new code in index.android.js:
Sentry.config("myDSN", {...}).install();
codePush.getUpdateMetadata().then((update) => {
if (update) {
Sentry.setVersion('codepush-' + update.label); // the label is correctly set up to a certain point, then becomes "null"
Sentry.setExtraContext({
these: 'seem_to_survive',
});
Sentry.setTagsContext({
'my_tags': 'survive_as_well',
});
Sentry.setUserContext({
username: 'worksfine'
});
}
}
I tried causing crashes in various parts of the app. The release tag is initially set to something like com.mypackage-codepush-v12 (in my login component) but if the crash is further down the app (in a different component) it turns to com.mypackage-null. The only difference I’ve been able to observe between the components is that one has a call to setUserContext (which I update upon login) and the next one has no such call, but it seems far fetched that this would make a difference.
(I cause an exception with let a = this_does_not_exist in each case, so the error is the same).
Thanks for pointing out the error with the callback!
which should tackle this problem.
I made sure the native client is only initialized once, which is the only reason I can think of why this is happening.
Please try it and tell me if it’s working.
I tried to latest version (0.14.5) but no luck, the issue is still the same. I guess there must be some misconfiguration I am doing, but I can’t think of what it is.
I logged the calls to setVersion() (on the native side with adb logcat) but saw only one that sets the version correctly, so the issue is somewhere else.