Allow filtering errors from host-environment SDKs

[bagedevimo]

Problem Statement

Our site frequently gets embedded into other peoples apps (Facebook, TikTok, Afterpay, Klarna, etc) via them doing their own "in-app browser" type thing. This means our code is running in whatever javascript environment they have set, and we have little control of some of the code that gets injected into the page, same as a browser extension does.

Unlike a browser extension, these aren't filtered out by Sentry's wonderful issue filters and just fill our javascript issue tracking with unsolvable noise.

For example:

These are almost certainly coming from https://www.fillr.com/ which is embedded into the Afterpay mobile app, per the user agent: Mozilla/5.0 (Linux; Android 14; SM-S918B Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/132.0.6834.122 Mobile Safari/537.36 AfterpayMobile/5520

Solution Brainstorm

Similar to "filter issues from known extensions", add a "filter issues from known embedders" feature which uses that magic ( i assume you look for extension IDs in backtraces? ) but does some other magic for this use case instead. Not really idea what that magic would be sorry, real PITA.

Product Area

Ingestion and Filtering

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

Routing to @getsentry/product-owners-ingestion-and-filtering for triage ⏲️

[cobyeastwood183]

https://sentry.zendesk.com/agent/tickets/143990

[lforst]

Hi, we strongly discourage people from running global Sentry instances in "embeddables" (extensions, iframes, SDKs) and recommend following this guide for using the SDK in an isolated way so that global errors don't leak between instances: https://docs.sentry.io/platforms/javascript/best-practices/multiple-sentry-instances/

The street goes both ways if you don't adhere to this guide. If your users install a global Sentry instance (which they are encouraged to do), their data will leak into your instance, and in reverse, your data will leak into their instance.

[lforst]

I just realized that your website is being often accessed from in-app browsers. For that case I need to think some more.

[lforst]

Two things:

• First, for this case we've built the thirdPartyErrorFilterIntegration https://docs.sentry.io/platforms/javascript/configuration/filtering/#using-thirdpartyerrorfilterintegration which comes with a few gotchas and being a bit experimental.
• Second, if you can be specific about the errors (error messages) you're getting from these in-app browsers, we can add these errors to our "default error filter" list. Since these errors are not actionable for everybody, we can just apply a blanket filter.

[bagedevimo]

First, for this case we've built the thirdPartyErrorFilterIntegration https://docs.sentry.io/platforms/javascript/configuration/filtering/#using-thirdpartyerrorfilterintegration which comes with a few gotchas and being a bit experimental.

Yeah this is super cool and we're discussing it internally - we also use GTM which does load some third party code on our site and would be filtered out, but maybe we're okay with that. Definitely exploring it.

Second, if you can be specific about the errors (error messages) you're getting from these in-app browsers, we can add these errors to our , "default error filter" list. Since these errors are not actionable for everybody, we can just apply a blanket filter.

Do you want links to the sentry issues, or copy-pastes of out of the error messages?
https://delivereasy.sentry.io/issues/4533644610/?project=5636949&query=is:resolved&statsPeriod=7d&stream_index=0

TypeError: Cannot read properties of null (reading 'startGetFields')
null is not an object (evaluating 'this.fillrFrame.startGetFields')

Is the one we get from fillr constantly, which we're now ignoring via the client side ignore feature.

We think these two are also fillr, but are less confident:

https://delivereasy.sentry.io/issues/4542548060/?project=5636949&query=is:unresolved%20fillr&statsPeriod=7d&stream_index=0

TypeError
undefined is not an object (evaluating 'window.PopWidgetInterface.startMonitor')

and https://delivereasy.sentry.io/issues/4512198047/?project=5636949&query=is:unresolved%20fillr&statsPeriod=7d&stream_index=1

TypeError
undefined is not an object (evaluating 'window.PopWidgetInterface.getFields')

[lforst]

@Dav1dde do you think we could *evaluating 'window.PopWidgetInterface.* to some relay filter list? It seems to be from the afterpay app.

@bagedevimo are you using fillr yourself?

[Dav1dde]

@lforst yes, don't even have to add it to Relay. We can do it like Chunkload and Hydration errors in Sentry: https://github.com/getsentry/sentry/blob/6c8211bf06f2c4054369cafbb45dfd3feb001fd5/src/sentry/ingest/inbound_filters.py#L339-L373

[lforst]

don't even have to add it to Relay

wouldn't it be faster (computing-wise) or whatever in Relay?

[Dav1dde]

wouldn't it be faster (computing-wise) or whatever in Relay?

These rules are passed down to Relay, Relay evaluates them, but you can define them in Sentry.

[bagedevimo]

@bagedevimo are you using fillr yourself?

Nope

[andreiborza]

We're still investigating this, thanks for all the extra info.