-
-
Notifications
You must be signed in to change notification settings - Fork 461
Description
In SentryClient.java, this is the implementation of sendEvent:
public void sendEvent(EventBuilder eventBuilder) {
if (!Util.isNullOrEmpty(release)) {
eventBuilder.withRelease(release.trim());
if (!Util.isNullOrEmpty(dist)) {
eventBuilder.withDist(dist.trim());
}
}
if (!Util.isNullOrEmpty(environment)) {
eventBuilder.withEnvironment(environment.trim());
}
if (!Util.isNullOrEmpty(serverName)) {
eventBuilder.withServerName(serverName.trim());
}
for (Map.Entry<String, String> tagEntry : tags.entrySet()) {
eventBuilder.withTag(tagEntry.getKey(), tagEntry.getValue());
}
for (Map.Entry<String, Object> extraEntry : extra.entrySet()) {
eventBuilder.withExtra(extraEntry.getKey(), extraEntry.getValue());
}
runBuilderHelpers(eventBuilder);
Event event = eventBuilder.build();
sendEvent(event);
}In particular - default extras and tags, coming from a parsed DSN for example - seem to override event-specific extras and tags with the same key. I'd consider this unwanted behaviour. A default is nothing more than a default, i.e. a value that is reported when nothing else is there. But if there is a specific value, then this specific value should take precedence.
My use case why I stumbled upon this was that I wanted to have a single tag to distinguish between fatal (reported the built-in uncaught exception handler of Sentry) and non-fatal (reported by my own machinery) crashes, and to mark them I wanted to introduce a tag exception-type. Since I cannot easily change the implementation of Sentry's uncaught exception handler, I thought I could simply give the tag ?tags=exception-type=fatal as default parameter to my DSN and have this used by the exception handler events, while in my own events I'd configure my event .withTag("exception-type=non-fatal") and that would override the default value.