The default behaviour sets a fingerprint but that contradicts the documentation

[Caerbannog]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:

Version:

4.5.3

Description

The documentation for grouping reads:

If a stack trace or exception is involved in a report, then grouping will only consider this information.
...
As a fallback, the message of the event will be used for grouping.

It took me some time to undestand that this isn't true anymore for the '@Sentry/node' (it was probably true for the old 'raven' package).

The following line currently sets a fingerprint for all exceptions that have a message:

sentry-javascript/packages/hub/src/scope.ts

Line 192 in 1d64ace

event.fingerprint = event.fingerprint.concat(event.message);

Here is an exemple of user code triggering this behaviour:

Sentry.captureException(new Error(`Invalid date received: ${dateInput}`));

In this case Sentry will sadly not group exceptions for different values of dateInput.
This is not easy to understand from a user's point of view, because the fingerprint information is hard to find on the Sentry website. You have to know how to download the JSON of events (click on "JSON" next to the event date), because it is the only place where the fingerprint is visible.

A quick fix for users is to unset the fingerprint before each captureException call:

Sentry.configureScope((scope) => {
  scope.setFingerprint(['{{ default }}']);
});

I believe that the documentation for grouping should be updated or the package behaviour changed to be explicit.

[kamilogorek]

Thanks for the detailed description. We are aware of this, however, it's a breaking change, since it'd "de-group" quite a lot of errors for some high-volume users.
There's a PR for fixing this already and we'll merge it before releasing v5 – #1831

Cheers!

[jektvik]

Is the current description as per: https://docs.sentry.io/data-management/rollups/?platform=csharp
accurate ? The {{default}} fingerprint is mighty confusing, What's the difference for setting it and not setting it ?
Quite specifically, I am currently trying to solve this scenario:
Example: Merge a lot of groups into one group (groups are too small)
And have opted to attach the {{default}} fingerprint to all logs with any other fingerprint, and it seems to work fine. But the documentation suggests that this should not be done and I can't work out why ?

[untitaker]

@jekusz Did you use to have multiple issues for what you consider the same error? Then setting a fingerprint that does not include {{ default }} is the way to go.

Do you have a single issue that contains multiple unrelated events because our grouping heuristic is not considering a particular aspect (such as some data in extra) in the event data? Then you can set a fingerprint with {{ default }} + a stringified version of that aspect to split up the issue by that.

[jektvik]

@untitaker I am solving the first scenario in your response (i.e. many into one) and, because of a misunderstanding, have already produced plenty tickets with say {error, default} fingerprints. And it works perfectly fine, they all get grouped into one event group though previously they would not be. Technically I am fine, but as you noted, it's opposite to what the documentation says one should do, so would really want to understand what's the risk here. I.e. I can't fathom what does the {default} fingerprint change here ?

[untitaker]

@jekusz the documentation is supposed to be correct. Could you post links to the relevant (sentry-)issues here?

[jektvik]

Here's a link to a bunch of events that get grouped into a single collection, even though they all contain the default fingerprint:
https://sentry.io/reviso/core-app/issues/852553001/events/8850697bf89645e1a3679426f3da08ec/
I can't say I can understand from the documentation, what does the presence of the {default} fingerprint change in this case ?

[untitaker]

Could you tell me which events (by ID) you would not want to have in this group, and which events are correctly in this group? I am very confused about what you want to achieve.

[jektvik]

@untitaker let me reiterate: I am achieving exactly what I need to, this is not the problem.
The problem is that I am doing it against the documentation's advise by appending the "default" fingerprint to the events. The documentation says that I should not. I'm keen to understand how and when is this gonna cause me problems.

[mitsuhiko]

Your event appends default as fingerprint and not {{ default }}. As such you are not actually appending a default value at all.

[mitsuhiko]

So maybe the docs are not very good on this and we're actually working on visualizing what happens on grouping. This is what is supposed to happen:

• send no fingerprint or fingerprint set to ["{{ default }}"]: default grouping applies
• set fingerprint to ["some-value"]: all events are grouped together
• set fingerprint to ["{{ default }}", "some-value"]: all events are subdivided below the default group for some-value.

The latter means that if you for instance have an event that looks completely the same as another they would normally end up in the same group. However if you add as last argument to fingerprint a value like your current HTTP request path you could force errors to go to separate issues with one issue per request path.

Does that make more sense?

And to clarify something: {{ default }} is the default fingerprint, default is just some random value. Your events sent default as fingerprint and not {{ default }} so the default fingerprint is never added.

[jektvik]

I can see much of the confusion here is on my misreading/mistyping of the "{{ default }}" fingerprint as "default", thanks for pointing that out.

@mitsuhiko I like how you're breaking it down in your comment, it's clear, at least for me.

[OyvindSabo]

This is what is supposed to happen:

• send no fingerprint or fingerprint set to ["{{ default }}"]: default grouping applies
• set fingerprint to ["some-value"]: all events are grouped together
• set fingerprint to ["{{ default }}", "some-value"]: all events are subdivided below the default group for some-value.

Hi, so far all of the fingerprinting examples I have seen use an array of at most two values. I'm wondering, can the fingerprint be of arbitrary length? Let's say I would want to extend the default by two values. Can I set fingerprint to...

["{{ default }}", "valueA", "valueB"]

...or would I have to combine all of the additional values into one string?

["{{ default }}", `${valueA}${valueB}`]

Thanks

Edit: I found an example with three values in the documentation, so I assume that it is indeed possible to supply more than two values.

[kamilogorek]

@OyvindSabo you are correct, length of fingerprints array is not restricted