[HELP NEEDED] Sentry.thirdPartyErrorFilterIntegration overwhelms my quota by not not filtering errors correctly

[gabrielecirulli]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

8.32.0

Framework Version

Svelte 4.2.19

Link to Sentry event

https://2048-ip-holding-bv.sentry.io/issues/7739542/?project=4507408148856912&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=issue-stream&statsPeriod=24h&stream_index=7

Reproduction Example/SDK Setup

No response

Steps to Reproduce

Reproduction is difficult because the issue stems from third-party ad code injected by the Ezoic Standalone SDK. The quality and error rate are unpredictable during user sessions, and we have no control over when the errors occur since the code is injected by third parties.

However, the problem should be visible through the provided event link in Sentry. If you look at the stack trace you'll notice that:

• All except 1 of the stack frames are from a script /ym.0.js. This is a third-party script
• The bottom stack frame is considered part of my node_modules: node_modules/.pnpm/@[email protected]/node_modules/@sentry/browser/build/npm/esm/helpers.js

My thirdPartyErrorFilterIntegration is set to "drop-error-if-exclusively-contains-third-party-frames" and it should be dropping these errors completely, but I believe it doesn't due to that one stack frame at the bottom.

This is thoroughly overwhelming my quotas: within 24 hours I've blown through the 50k errors in my account and I'm at a loss for how to continue. I've switched the mode to "drop-error-if-contains-third-party-frames" for now but this will kill my visibility on errors that are partially related to my code. It is ok as a temporary measure, but I need a long-term fix.

---

Here is a description of my setup:

• Vite TypeScript app.
• Using Svelte as a front-end framework
• Svelte is initialized by importing the SDK into my bundled code and with the following config:

// This module is a convenience to ensure config across main and worker initializations
import { init, thirdPartyErrorFilterIntegration } from "@sentry/svelte";

declare global {
  const SENTRY_FINGERPRINT_FOR_FILTERING_OUT_ERRORS_FROM_THIRD_PARTY_CODE: string;
}

init({
  dsn: "<snip>",
  maxBreadcrumbs: 200,
  integrations: [
    thirdPartyErrorFilterIntegration({
      filterKeys: [SENTRY_FINGERPRINT_FOR_FILTERING_OUT_ERRORS_FROM_THIRD_PARTY_CODE],
      behaviour: "drop-error-if-contains-third-party-frames",
    }),
  ],
});

Then, the Sentry fingerprint is set up as follows in vite.config.ts (this snippet is heavily altered to avoid listing the other plugins):

import { sentryVitePlugin } from '@sentry/vite-plugin';
import { defineConfig, loadEnv } from 'vite';

const SENTRY_FINGERPRINT_FOR_FILTERING_OUT_ERRORS_FROM_THIRD_PARTY_CODE =
  '<my_key_here>';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    // ... Other unrelated plugins ...

    // Last plugin
    sentryVitePlugin({
      applicationKey:
        SENTRY_FINGERPRINT_FOR_FILTERING_OUT_ERRORS_FROM_THIRD_PARTY_CODE,
      org: '<snip>',
      project: '<snip>',
    }),
  ],
  define: {
    SENTRY_FINGERPRINT_FOR_FILTERING_OUT_ERRORS_FROM_THIRD_PARTY_CODE:
      JSON.stringify(
        SENTRY_FINGERPRINT_FOR_FILTERING_OUT_ERRORS_FROM_THIRD_PARTY_CODE
      ),
  },
});

Just to be sure, I also verified that my bundled code also contains the following bits of JS that should be identifying the modules. Notice how the app key is in there:

!(function () {
  try {
    var e =
        "undefined" != typeof window
          ? window
          : "undefined" != typeof global
            ? global
            : "undefined" != typeof self
              ? self
              : {},
      t = new e.Error().stack;
    t &&
      ((e._sentryDebugIds = e._sentryDebugIds || {}),
      (e._sentryDebugIds[t] = "<snip>"),
      (e._sentryDebugIdIdentifier = "<snip>"));
  } catch (i) {}
})();
var e =
  "undefined" != typeof window
    ? window
    : "undefined" != typeof global
      ? global
      : "undefined" != typeof self
        ? self
        : {};
(e._sentryModuleMetadata = e._sentryModuleMetadata || {}),
  (e._sentryModuleMetadata[new e.Error().stack] = Object.assign(
    {},
    e._sentryModuleMetadata[new e.Error().stack],
    { "_sentryBundlerPluginAppKey:<my_key_here>": !0 },
  ));

---

Dependencies:

• svelte 4.2.19
• @sentry/svelte 8.32.0
• @sentry/vite-plugin 2.22.4
• @sveltejs/vite-plugin-svelte 3.0.2
• typescript 5.6.2
• vite 5.4.8

...and a couple more

Expected Result

Errors such as the one linked, and many more in my dashboard, should have been discarded clientside, but somehow the snippet shown in the bottom stack frame, presumably causes them to be included (I say presumably because I don't know for sure this is the case but I presume so from reading the source of thirdPartyErrorFilterIntegration)

Here's the relevant snippet being included in the stack trace, from file node_modules/.pnpm/@[email protected]/node_modules/@sentry/browser/build/npm/esm/helpers.js

      // Attempt to invoke user-land function
      // NOTE: If you are a Sentry user, and you are seeing this stack frame, it
      //       means the sentry.javascript SDK caught an error invoking your application code. This
      //       is expected behavior and NOT indicative of a bug with sentry.javascript.
      return fn.apply(this, wrappedArguments);

Here's a link to the file in question in this repo.

I don't know why this function is part of the stack trace.

Actual Result

Errors that should be filtered according to "drop-error-if-exclusively-contains-third-party-frames" are not filtered, overwhelming my quota. About 40k of the 50k errors I've received in the last 24 hours should have been dropped. It seems like a single stack frame is preventing them from being dropped.

You can review the following samples. Please note how the last stack frame always originates from some Sentry code and is presumably blocking the event from being dropped.

• https://2048-ip-holding-bv.sentry.io/issues/8598250/?project=4507408148856912&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=issue-stream&sort=freq&statsPeriod=24h&stream_index=0
• https://2048-ip-holding-bv.sentry.io/issues/7739542/?project=4507408148856912&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=issue-stream&sort=freq&statsPeriod=24h&stream_index=1
• https://2048-ip-holding-bv.sentry.io/issues/8597330/?project=4507408148856912&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=issue-stream&sort=freq&statsPeriod=24h&stream_index=2
• https://2048-ip-holding-bv.sentry.io/issues/8597336/?project=4507408148856912&query=is:unresolved%20issue.priority:%5Bhigh,%20medium%5D&sort=freq&statsPeriod=24h&stream_index=7
• https://2048-ip-holding-bv.sentry.io/issues/8574927/?project=4507408148856912&query=is:unresolved%20issue.priority:%5Bhigh,%20medium%5D&sort=freq&statsPeriod=24h&stream_index=8
• https://2048-ip-holding-bv.sentry.io/issues/8599878/?project=4507408148856912&query=is:unresolved%20issue.priority:%5Bhigh,%20medium%5D&sort=freq&statsPeriod=24h&stream_index=11

[lforst]

Hi, since you said you set the behaviour to "drop-error-if-exclusively-contains-third-party-frames", and there is a frame from your own code in the stack frame, the event should not be dropped and everything is behaving as designed.

In this case, since the third-party script path doesn't seem to change you can use the denyUrls option: https://docs.sentry.io/platforms/javascript/configuration/filtering/#using-allowurls-and-denyurls

Maybe with something like denyUrls: [/\/ym\.1\.js$/, /\/ym\.2\.js$/]

[gabrielecirulli]

@lforst You're right that there's a frame from my code in the samples, but this frame is auto-injected by the Sentry SDK outside my control and it breaks the expectation of how "drop-error-if-contains-third-party-frames" should work.

I can't control the presence of this frame as it is injected automatically, nor can I easily instruct the SDK to ignore it. As a result, any error from third-party code will include this frame if it interacts with the instrumentation. To me, this looks like a design flaw in the SDK or in "drop-error-if-contains-third-party-frames" as it does not behave as implied in its name for unpredictable reasons outside my control.

Yes, from a technical perspective the frame in question is from my code, but I have no control over it being there, and all of the errors I linked should have been dropped when following the intended behavior of "drop-error-if-contains-third-party-frames".

Your suggestion of using denyUrls would not work for me, because the scripts change constantly and are dependent on the current ads on the page.

I also want "drop-error-if-contains-third-party-frames" to correctly identify errors in third-party scripts that originate from an action I took in my code, such as interacting with the ad network's SDK. Therefore plainly denying all external URLs would also not work.

This seems like a significant issue for any Sentry customer running ads, as it undermines trust in "drop-error-if-contains-third-party-frames". It also has serious financial or service implications, as in my case, where it caused me to exceed my monthly quota in a single day, leaving me without error observability for the rest of the month.

[lforst]

From my point of view, this works as expected. The integration does as much as is technically possible. The SDK is part of your code (i.e. code you included into your bundles), and you likely wouldn't wanna throw away events if the SDK is causing bugs.

As you have already correctly identified, if you really want to get rid of these events automatically, you can set "drop-error-if-contains-third-party-frames".

You have all the possibilities beforeSend, which you can use to drop events at will. I came up with and built the thirdPartyErrorFilterIntegration and I can tell you there is nothing more I can think of we could do. If you have a suggestion, please let us know!

[gabrielecirulli]

@lforst I agree with you that, from a technical standpoint, the integration functions as expected, and I understand that events from the SDK shouldn't be discarded outright.

However, this setup makes it very difficult for me to filter out errors caused by third-party code where I am neither the source nor the caller. How are your other clients handling this, particularly those with ad-heavy sites? I would be surprised if I'm the only one facing this challenge.

As mentioned earlier, this issue has significant business implications for me. My options seem to be very limited:

• Discard all events that include third-party code, even in cases where I am the caller (these sorts of errors currently exist and I am unable to track them or I'd go over my quota).
• Build my own filtering system, though I'm unsure where to begin. If thirdPartyErrorFilterIntegration is unable to offer this functionality given you've built the SDK, I'm not confident I could develop a better solution. I don't have the insight for it.
• Opt out of the bundled Sentry JS SDK entirely?

None of these options is satisfactory.

Looking again at the code in the stack trace, it appears to be glue code. Even the comment indicates this code isn't meant to be treated as part of the stack trace, but rather that an error occurred downstream after Sentry wrapped global objects with its own handlers:

      // Attempt to invoke user-land function
      // NOTE: If you are a Sentry user, and you are seeing this stack frame, it
      //       means the sentry.javascript SDK caught an error invoking your application code. This
      //       is expected behavior and NOT indicative of a bug with sentry.javascript.
      return fn.apply(this, wrappedArguments);

I feel that no viable solution is being proposed here. I only have a choice between missing critical errors related to third-party code or severely exceeding my budget and quota by letting too many unnecessary event through the filter over a technicality.

I would agree with your position if the code in the stack trace was unrelated, but it’s directly tied to the core functionality of the Sentry SDK. This piece of code causes another part of your SDK not to work as intended. You're right, the respective units of code work exactly as intended. The interaction between them is a bug with serious ramifications.

[lforst]

I feel like we are aligned. Sadly there is not much more to add.

We cannot exempt the SDK code, since from the perspective of the SDK it is indistinguishable from your own application code (look at the minified stack trace).

The last stack frame is not "glue code" - in fact it is mission critical. It is literally what caught and reported the error you see in sentry.

[lforst]

The only thing I can come ip with is to pop this stack frame from the stack - I need to review whether that is possible somehow.

[gabrielecirulli]

I totally understand that the code is mission critical and should not be exempt, but please understand that from my perspective as a customer of Sentry I am not interested nor involved into the decisions that go into building the SDK.

The code in question is an implementation detail of the SDK itself, and for the same reason as implementation details should not be within the purview of the consumers of a piece of code, the same logic should apply here.

The SDK should be intelligent enough to tag these specific instances and give me an option to opt out of them. If you will, there should be a third option "drop-error-if-contains-third-party-frames-other-than-sentry-internal-implementation-frames" :)

[lforst]

Thanks for raising this then! Gonna backlog this as a feature request. It is uncertain whether we can figure something out.

[gabrielecirulli]

Thanks. In the meantime do you have any insight on how other customers with ad networks on their site handle this issue? It would be very useful to know.

[lforst]

I don't have specific insights but I recommend checking whether any of the methods we provide to filter events fits your use case: https://docs.sentry.io/platforms/javascript/configuration/filtering/

Most of the time there is at least one common denominator to rule out a class of errors.

[tsirlucas]

is it safe to assume that if the frames array length is bigger than 1, then the first frame is going to be the sentry call OP is talking about? is it possible for you guys to tag these frames with something like isSentryCall?

i did some tests and best solution i can find is using beforeSend to filter based on filename, but always ignore the first frame cause its going to be the sentry call which is my own code

if we can have some kind of flag in the frame it would be really nice the integration can even take advantage of this flag to implement what OP requested

[lforst]

is it possible for you guys to tag these frames with something like isSentryCall?

Technically impossible - if certain requirements are lifted, flakeyly.

The solution I am eyeing is just popping frames in the event processing.

[patroza]

is it possible for you guys to tag these frames with something like isSentryCall?

Technically impossible - if certain requirements are lifted, flakeyly.

The solution I am eyeing is just popping frames in the event processing.

How is the progress?
I am just running into this myself. After some days of blissful silence..
Now I got this popping up: https://macs-holding.sentry.io/issues/6347573534/events/latest/?alert_rule_id=15804510&alert_type=issue&notification_uuid=16b5e8cf-f62c-41c0-adb9-34d516d64fce&project=4504671195299840&referrer=latest-event

I understand Sentry SDK is technically in my bundle thus considered my code, but it clearly is a third party script causing an error and Sentry catching it. it's like a self fulfilling prophecy :D

can't you just rename the function to "__SHOULD_BE_IGNORED__sentryWrapped" and filter that out? I guess the issue is minification.

[lforst]

@patroza, we haven't been looking at this recently.

Thanks for linking the event - always helps in finding edge cases.

You are completely right that Sentry is getting picked up as "your" code - which is hella shitty. You are also right that minification is the reason we cannot use function names as a identificator for dropping SDK frames is minification.

I just had an idea though that I wanna write down for posterity: This has the possibility to be a bit flakey but we could generate a stack trace in our wrapping code, parse the stack, grab the function name off the first stack frame, and drop all frames that have the same function name and are within a window of the colno (lineno is probably way too agressive in a minified situation).