Fingerprint rules: allow regular expressions to be used as matchers

[arifken]

Problem Statement

Currently, fingerprint rules matchers support only glob patterns (as described here). However, there are often times that it would be useful to ignore parts of a field that can change when grouping issues.

Consider the following error.value:

Can't access the Fragment View's LifecycleOwner for MyGreatFragment{35acebf} (e962sd9a-994c-4e8c-a441-x9367c8e794d id=0xc) when getView() is null i.e., before onCreateView() or after onDestroyView()

In this particular case, it would be really great to pre-process this message by removing unique values such as view UUIDs, memory addresses, etc, while still grouping issues that match the rest of the message. Ideally, I'd like to match on

Can't access the Fragment View's LifecycleOwner for MyGreatFragment{ignored} (ignored id=ignored) when getView() is null i.e., before onCreateView() or after onDestroyView()

Solution Brainstorm

I'm not entirely sure how this would look in Sentry's matcher syntax, but I'm imagining something like rex in Splunk. For the example above

rex field=error.value mode=sed "s/([a-z0-9]+-){4}[a-z0-9]+/ignored/g" 

If that could be used to preprocess a field before the matchers (as they currently exist) are applied, that would allow us to globally "ignore" identifiers such as UUIDs or memory addresses without the matcher knowing about the specific error message.

Product Area

Ingestion and Filtering

[getsantry]

Auto-routing to @getsentry/product-owners-issues for triage ⏲️

[scttcper]

I've passed this to our grouping team, but in the interim you can usually do some massaging in the beforeSend function of the sdk to strip text or add a fingerprint https://docs.sentry.io/platforms/javascript/configuration/filtering/#using-hints