anyhow errors are grouped incorrectly

[danechitoaie]

Environment

Sentry 0.36.0

Any idea would could cause different errors logged from different parts of the app with different messages (using anyhow::anyhow!()) to be incorrectly grouped?

See the above print screen.
Why is that error grouped with the others when it's different error.

One was logged with

let err_msg = "Embeddings request failed!";
let err_anyhow = anyhow::anyhow!(err_msg);
sentry::integrations::anyhow::capture_anyhow(err_anyhow);

and the other with

let err_msg = "Create thread request failed!";
let err_anyhow = anyhow::anyhow!(err_msg);
sentry::integrations::anyhow::capture_anyhow(err_anyhow);

Can this be because both errors are anyhow errors just with different messages? And somehow they have same fingerprint and Sentry groups them by that?

Would me setting a custom fingerprint help?

[lcian]

Hey @danechitoaie, could you try scrolling to the bottom of the issue page? There will be a section you can expand called "Event Grouping Information" which will give you more information around this.
Feel free to share it here if you need more help to understand it or if you think we might have a bug :)

[danechitoaie]

Hi.
Trying to provide more details in a simplified way:

Given the following code:

    let err1 = anyhow::anyhow!("Some error!");
    sentry::integrations::anyhow::capture_anyhow(&err1);

    let err2 = anyhow::anyhow!("Other error!");
    sentry::integrations::anyhow::capture_anyhow(&err2);

In Sentry they appear like this:

with the following "Event Grouping Information":

So I'm not sure if this is the intended way. Basically they both are simple anyhow errors, but they are different errors generated in different place in the code, so in my opinion I think they should not be grouped.

Anyway, in my case I decided to use a custom scope.set_fingerprint(...); which now logs them separately, but I think that should be the default way... so maybe the issue/bug it's just with anyhow errors.

[lcian]

Thanks for adding more information @danechitoaie !

What happens here is that anyhow errors all have empty stack traces which causes them to be all grouped together as they all have the same (empty) stack trace.

Instead of using scope.set_fingerprint, you can run the binary with RUST_BACKTRACE=1, this way anyhow will collect the backtrace which will be sent within the event by the SDK and grouping will be correct.

Please note that this could possibly break your grouping for other issues as they might be reported with a different stack trace when the flag is enabled

[lcian]

There's more to it, this is actually similar to #723
What's happening is that when RUST_BACKTRACE is unset we still try to parse the backtrace, resulting in an empty stack trace sent by the SDK.
Our grouping logic still considers an empty stack trace as a valid one, so it will use that to determine the group.
If the anyhow isn't providing the backtrace, we need to noop.
That way either sentry-backtrace will provide a partial backtrace (up until the point sentry::capture_anyhow is called) if it's enabled, otherwise the backtrace will be empty and we will group according to the error message.