getsentry/sentry-javascript

thirdPartyErrorFilterIntegration mis-categorizing native frames in stacktrace

Closed this issue · 5 comments

md384 commented

Is there an existing issue for this?

How do you use Sentry?

Self-hosted/on-premise

Which SDK are you using?

@sentry/react

SDK Version

10.11.0

Framework Version

React 18.2.0

Link to Sentry event

No response

Reproduction Example/SDK Setup

Using thirdPartyErrorFilterIntegration with the apply-tag-if-contains-third-party-frames behaviour

captureConsoleIntegration({ levels: ['error'] }),
thirdPartyErrorFilterIntegration({
  filterKeys: ['some-key'],
  behaviour: 'apply-tag-if-contains-third-party-frames',
}),

Steps to Reproduce

The following example

  Promise.allSettled([
    Promise.resolve(33),
    new Promise((resolve) => setTimeout(() => resolve(66), 0)),
    99,
    Promise.reject(new Error('an error')),
  ]).then((values) => values.forEach((value) => console.error(value)))

creates a stacktrace with a frame

{
  "function": "Array.forEach",
  "filename": "<anonymous>",
  "abs_path": "<anonymous>",
  "in_app": true,
  "data": {
    "client_in_app": true
  }
}

This frame appears to cause the error as tagged with third_party_code as true. This is the only frame in the stacktrace not from our bundle - thirdPartyErrorFilterIntegration appears to be working for us correctly elsewhere i.e. stacktraces without frames from native code.

I have seen similar mis-categorizations with Promise.all and Promise.allSettled so I believe it is any native frame.

Expected Result

Frames for native code that do not cause an error should not set the third_party_code tag.

Actual Result

third_party_code is true

Additional Context

Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.

Lms24 commented

Hey, thanks for reporting! We need to think a bit about how to solve this since it's probably not easy impossible to distinguish such native frames from within your code from native frames in 3rd party code. My idea for now would be to always ignore "filename": "<anonymous>" frames but I still want to think a bit about this a bit.

md384 commented

@Lms24 here are some more example I found

{
  "function": "async Promise.allSettled",
  "filename": "index 0",
  "abs_path": "index 0",
  "in_app": true,
  "data": {
    "client_in_app": true
  }
}

and

{
  "function": "async Promise.all",
  "filename": "index 1",
  "abs_path": "index 1",
  "in_app": true,
  "data": {
    "client_in_app": true
  }
}

So "filename": "<anonymous>" will not work for these. However for each case I've seen and only for native frames, there are no lineno or colno attributes so perhaps you can ignore any frame without a lineno and colno

  • 👀1
Lms24 commented

Thanks for the suggestion! I decided to go with requiring at least one of lineno and colno properties: #17693

github-actions commented

A PR closing this issue has just been released 🚀

This issue was referenced by PR #17693, which was included in the 10.13.0 release.