Custom fingerprint added to GenServer call crashes by client

[msfstef]

Issue Description

The client adds a custom fingerprint when the crash reason is due to a GenServer.call :timeout or :noproc, with the form [type, "genserver_call", call_args], see below:

sentry-elixir/lib/sentry/logger_handler.ex

Lines 484 to 488 in f83b508

	Keyword.put_new(sentry_opts, :fingerprint, [
	Atom.to_string(type),
	"genserver_call",
	inspect(call)
	])

Because of this, any fingerprinting done on the server side is overridden because custom client fingerprints are prioritised.

Since the call arguments might contain unique IDs and other values, what we've observed is that we get flooded with individual error reports, not grouped at all, where the default grouping or stack-trace grouping would've done a much better job at grouping these together.

I've added a workaround using the :before_send hook to remove the custom fingerprint added by the client itself, but wanted to raise that this seems like unexpected behaviour, for the client to add this kind of hard fingerprinting rule that I feel would often not manage to actually group events together.

Reproduction Steps

Run a GenServer.call(server, :timeout, 1) with a handler that sleeps a bit to reproduce timeout exits.

Expected Behavior

Events should not have a custom fingerprint rule unless we explicitly set one in the logger metadata.

Actual Behavior

The GenServer crashes end up with a custom client fingerprint that does not group events together because it includes the call arguments that are often unique.

Elixir Version

1.18.4-otp-28

SDK Version

11.0.1

Integration and Its Version

No response

Sentry Config

No response

[linear]

ELIXIR-29 Custom fingerprint added to GenServer call crashes by client

[solnic]

Thank you for this detailed report!

@whatyouhide what's the reasoning behind including args in the fingerprint?

[whatyouhide]

If you don't include args you might get errors related to very different calls fingerprinted and grouped together. I personally think we should lean on too many errors rather than missing errors whenever situations are ambiguous as this one is. Open to ideas.