-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
feat(nestjs): Handle non-HTTP contexts in SentryGlobalFilter #24326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -179,6 +179,25 @@ class SentryGlobalFilter extends BaseExceptionFilter { | |
| return; | ||
| } | ||
|
|
||
| // Custom context types (necord, ...) run through ExternalContextCreator and have no HTTP adapter. | ||
| // BaseExceptionFilter expects an HTTP adapter and cannot reply on those hosts. | ||
| if (contextType !== 'http') { | ||
| if (!isExpectedError(exception)) { | ||
| captureException(exception, { | ||
| mechanism: { | ||
| handled: false, | ||
| type: `auto.${contextType}.nestjs.global_filter`, | ||
| }, | ||
| }); | ||
| } | ||
|
|
||
| if (exception instanceof Error) { | ||
| this._logger.error(exception.message, exception.stack); | ||
| } | ||
|
|
||
| return; | ||
| } | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Feat missing integration or E2E testMedium Severity This feat only adds unit tests for the new Triggered by project rule: PR Review Guidelines for Cursor Bot Reviewed by Cursor Bugbot for commit 00688ae. Configure here. |
||
|
|
||
| // HTTP exceptions | ||
| if (!isExpectedError(exception)) { | ||
| captureException(exception, { | ||
|
|
||


There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you test the behavior for this? usually we rethrow exceptions to not interfere with user application behavior. however, there are exceptions for instance if you look at the rpc branch in this file. so not entirely sure this is correct, depends a bit on how the framework behaves here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, tested it against real Nest (10.4.15): registered
SentryGlobalFilterasAPP_FILTERand ran a throwing handler throughExternalContextCreatorwith anecordcontext type, the same way necord wires its handlers.The
returndoesn't swallow the error.ExternalExceptionsHandler.next()only uses the filter result if it's truthy, otherwise it falls back toExternalExceptionFilter, which rethrows. So the caller still gets the original error, same as without the Sentry filter, and we capture it once. The rpc branch works the same way: returning there falls through toBaseRpcExceptionFilter, which still sends the error back to the client (checked with@nestjs/microservices10.4.15). Nest master has the same fallback.One side effect: the error gets logged twice (our
_logger.errorplus Nest'sExternalExceptionFilter). I can drop our log line in this branch if you'd like, and I can also add the framework-level test to the PR.