Repository navigation
thirdPartyErrorFilterIntegration mis-categorizing native frames in stacktrace #17674
Description
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?
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.
Metadata
Metadata
Assignees
Projects
- Status
Activity
linear commentedon Sep 16, 2025
JS-948 thirdPartyErrorFilterIntegration mis-categorizing if Promise frames in stacktrace
[-]thirdPartyErrorFilterIntegration mis-categorizing if Promise frames in stacktrace[/-][+]thirdPartyErrorFilterIntegration mis-categorizing native frames in stacktrace[/+]Lms24 commentedon Sep 17, 2025
Hey, thanks for reporting! We need to think a bit about how to solve this since it's probably
not easyimpossible 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 commentedon Sep 17, 2025
@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 nolinenoorcolnoattributes so perhaps you can ignore any frame without alinenoandcolnoLms24 commentedon Sep 18, 2025
Thanks for the suggestion! I decided to go with requiring at least one of
linenoandcolnoproperties: #17693fix(core): Ensure builtin stack frames don't affect `thirdPartyErrorF…
github-actions commentedon Sep 22, 2025
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.