feat(core): Add addConsoleInstrumentationFilter utility#20790
Conversation
We want to leverage this for Node 26 to filter deprecation messages from IITM, but this could also be used by users if they want to silence certain things.
size-limit report 📦
|
There was a problem hiding this comment.
Overall LGTM (I btw also upvoted this: #20790 (comment))
|
added node-integration test, and made sure that this is properly applied in core actually instead of just in node! |
|
|
||
| interface ConsoleIntegrationOptions { | ||
| levels: ConsoleLevel[]; | ||
| /** | ||
| * Filter out console messages that match the given strings or regular expressions. | ||
| * These will neither be passed to the handler, and they will also not be logged to the user, unless they have debug enabled. | ||
| */ | ||
| filter?: (string | RegExp)[]; | ||
| } | ||
|
|
||
| /** |
There was a problem hiding this comment.
Bug: The filter option for the consoleIntegration is silently ignored in AWS Lambda environments because the Lambda-specific instrumentation bypasses the filtering logic.
Severity: MEDIUM
Suggested Fix
Modify the instrumentConsoleLambda function in packages/node-core/src/integrations/console.ts to incorporate the filter check. Before calling triggerHandlers and the original console method, evaluate the filter option. If the filter returns false, skip the instrumentation logic for that console call. This will align the Lambda environment's behavior with the standard console instrumentation.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/node-core/src/integrations/console.ts#L14-L24
Potential issue: In AWS Lambda environments, the `filter` option configured for the
`consoleIntegration` has no effect. The Lambda-specific console instrumentation wrapper,
`instrumentConsoleLambda`, directly patches console methods and calls Sentry handlers
without checking the `filter` configuration. The filtering logic exists in the core
`instrumentConsole` wrapper, but this is not used in Lambda environments. Consequently,
all console messages are processed regardless of the filter settings, potentially
leading to unwanted data being sent or processed.
There was a problem hiding this comment.
we'll accept this for now but I'll add a comment
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit fd4296d. Configure here.
| export function stringMatchesSomePattern( | ||
| testString: string, | ||
| patterns: Array<string | RegExp | ((value: string) => boolean)> = [], | ||
| patterns: |
There was a problem hiding this comment.
adjusted this to also accept a set, some short research showed that this is possibly slightly more performant this way anyhow (well, not that it matters I believe, but it should not hurt at least). And this means we do not need to constantly convert this from set to array in the instrumentation code.

We want to leverage this for Node 26 to filter deprecation messages from IITM, but this could also be used by users if they want to silence certain things.
Required for #20710