how Sentry captures and reports errors in dependency packages

[mighty knot]

I want to know how Sentry captures and reports errors in dependency packages. I used thirdPartyErrorFilterIntegration, but it didn't work.

[polar stone]

Hi @mighty knot. I'm happy to dig into this for you! I'll check my internal sources for answers to your question! :wave:

---

Based on the knowledge sources, I can help explain how Sentry handles errors from dependency packages and why thirdPartyErrorFilterIntegration might not be working as expected.

How Sentry Captures Errors from Dependencies

By default, Sentry captures all errors that occur in your application, including those from dependency packages (like node_modules). This is because bundled dependencies are treated as part of your application code during the build process.

Why thirdPartyErrorFilterIntegration May Not Filter Dependencies

According to the JavaScript troubleshooting documentation, there's an important limitation:

These errors will not be dropped if the stack trace contains frames from node_modules. Since these dependencies are bundled with your code during the build process, the SDK treats them as part of your application when evaluating whether an error is third-party.

The thirdPartyErrorFilterIntegration is designed to filter out errors from sources like:

• Browser extensions
• Code-injecting browsers
• Third-party widgets that inject code at runtime

It works by marking your JavaScript files with an "application key" during the build process. However, since your dependencies are bundled together with your code, they receive the same application key and are not considered "third-party" by this integration.

Alternative Filtering Strategies

For more precise control over which errors are sent, the documentation recommends:

1. Use the beforeSend callback to programmatically inspect and drop events based on custom logic
2. Use allowUrls and/or denyUrls to control which sources should be considered first-party or excluded entirely

These approaches give you more granular control over filtering errors from specific dependencies or sources.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: