Inbound Filter Outcome Reason

[smeubank]

Description
We want to be able to categorize why errors dropped by a serverside inound filter are dropped. In this specific case we are trying to analyze the full impact of filtering out hydration errors, but it maybe usefuly to do this in a more scalable way

link

If the filter is based on hyrdation error. Is this included in the "error message" reason? If yes could that be added to the outcome reason? error "message: hydration"

the in product toggle found in project inbound filter settings

[jjbayer]

Will be fixed by getsentry/sentry#57799.

[bruno-garcia]

This will really help when debugging customer who reach out about data not being in. "My replay is sampled but the error was dropped" and we dunno what filter was applied

[mydea]

Referencing getsentry/sentry-javascript#10036, as that may be related to this!

[smeubank]

@billyvg also stumbled across this, related to customers calling in and not having enough insight

[jjbayer]

Should be straight-forward to port hydration errors to generic filters now, which would give them a separate outcome reason. We just need to extend the Getter on Event to access exception.values.value. @iker-barriocanal maybe something for you?

[iker-barriocanal]

@smeubank do you have a list of filters we could target? I see special cases for hydration errors and chunk load errors. Getting reasons for these two specifically is quite straightforward.

[smeubank]

for a list for filters, we should be able to manage at least what is here and toggleable

• browser extensions
• health check (transations)
• legacy browsers
• localhost
• web crawlers
• hydration errors
• chunkLoadError(s)

[iker-barriocanal]

After discussing on Slack, the only missing filters without a reason in the above list are the hydration and chunk load errors.

[iambriccardo]

We are now working on the foundational elements needed to allow the expression of error message rules generically. This is the PR for reference: #3791.

The next steps are:

1. Implementing the new looping semantics
2. Implementing the rule generation in Sentry

[iambriccardo]

Will use this query to validate the new outcomes:

MATCH (outcomes)
SELECT reason, count(reason) BY reason
WHERE project_id = 11276 AND org_id = 1
AND outcome = 1
AND timestamp >= toDateTime('2024-07-01T10:30:30')
AND timestamp < toDateTime('2024-07-30T10:30:30')