Hello 👋 We're facing a situation similar to #957, whereby we have lots of errors that differ slightly in their stacktrace, meaning they are grouped differently when they are ostensibly the same error. Stacktrace differences typically occur in the 'framework traces', caused by slight variations in dependency versions over time. What we really care about for the purposes of fingerprinting are the 'application traces'.

The backtrace_cleanup_callback added in #1011 was a useful addition meaning that the application traces of our stacktraces no longer differ on dynamically generated template methods (such as app/views/welcome/view_error.html.erb in _app_views_welcome_view_error_html_erb__2807287320172182514_65600 at line 1). I understand that we could provide our own callback to this method and use the Rails::BacktraceCleaner to filter out framework traces and keep only our application traces, like so:

config.backtrace_cleanup_callback = lambda do |backtrace|
  Rails.backtrace_cleaner.clean(backtrace)
end

The problem with this approach is that it is lossy. We only want to filter the stacktrace for the purposes of fingerprinting, but we still want to be able to dig into the whole stack trace when we come to debug the error.

Proposal

I propose that the implementation of backtrace_cleanup_callback be changed slightly (as it's still new and presumably has limited adoption so far), so that it doesn't alter the original stack trace. It would have exactly the same API (i.e. a lambda) but would just store a filtered version in memory for the purposes of fingerprinting.

If changing the current property is not an option, a new config option could be provided (perhaps filter_backtrace_for_fingerprinting).

Or, if I've completely misunderstood how this works and it isn't lossy, could the documentation make this explicit?

Other approaches considered

I've toyed with the idea of manipulating the fingerprint itself using before_send, though there is no documentation on this and I'm not sure if it's supported:

config.before_send = lambda { |event, hint|
  event.fingerprint =CustomFingerprint.sample(event)
  event
}

What stopped me from investigating this further was that it felt like using a sledgehammer to crack a nut. The default Sentry grouping algorithm is great, most of the time, and I'd rather not reimplement it - I just want to tweak it to be a little more forgiving of environmental differences in stack trace.

I did also consider server-side fingerprinting to filter out framework traces, but we have a lot of applications to manage and a strong version control mantra, whereby manually editing this kind of thing in the Sentry UI really isn't ideal.

Thanks in advance for your time!