Repository navigation
dataCallback overwritten by angular plugin #477
Description
When using the angular plugin, the dataCallback method I set in the config options is overwritten by the plugin.
Raven.config("mydsn", {
dataCallback: function(data) {
console.log "my data callback was called";
return data;
}
}).install();The provided callback will be stored in _globalOptions.dataCallback during config(). After that, install() will call angularPlugin which calls Raven.setDataCallback - overwriting my callback. There are two solutions here:
- The plugin should create a wrapper method that first calls the already registered callback (if any) and then does it's own work.
- There should not only be one callback but several, registered in an array that will be called one after the other. The downside would be that:
- either the name for registering data callbacks would be called
setDataCallbackalthough it wouldn't set but add it - or the method would be renamed, breaking backwards compatibility. This could be avoided by keeping
setDataCallbackwhich would erase all other callbacks and addaddDataCallbackorregisterDataCallbackwhich would just add the callback to the array.
- either the name for registering data callbacks would be called
I could create a PR if one approach is acceptable.
Activity
thomasjachmann commentedon Jan 18, 2016
This is also true for the react-native plugin. There,
setTransportalso works the same and might lead to similar problems.benvinegar commentedon Jan 18, 2016
Thanks for reporting this.
My first inclination is to have both plugins just dig into Raven's internals and wrap
this._globalOptions.dataCallback(option 1), since that will quickly fix the problem and doesn't require us to modify Raven's public API. Since these are plugins maintained by us, I think touching the private API is okay.The flip side is that this is a recurring problem, and I'd like to see a longer term fix (e.g.
addDataCallbackor some other generic event API). But we've introduced a lot of thrash to Raven recently, and I think I'd like to hold out just a little longer on this.benvinegar commentedon Jan 18, 2016
cc @mattrobenolt
benvinegar commentedon Jan 18, 2016
Hmm, thinking about this more, just wrapping the internal callback can still result in situations where the callback is clobbered.
For example, if you call
setDataCallbackafterinstall, it would clobber any plugin's callbacks:Admittedly, that's not how we document this in the docs, but it could happen. Hmm.
thomasjachmann commentedon Jan 18, 2016
@benvinegar Right. That means the
dataCallbackoption andsetDataCallbackfunction should only be used by the user while the plugins should use a different way to register their data enhancements. On the other hand, a user might want to achieve just this: Use the plugin's exception handler but not it's data callback. But this is rather hypothetical.kamilogorek commentedon Sep 28, 2017
Already fixed