Uh oh!
There was an error while loading. Please reload this page.
fix(nestjs): Improve control flow exception filtering - #19524
Conversation
| */ | ||
| export function isExpectedError(exception: unknown): boolean { | ||
| if (typeof exception === 'object' && exception !== null) { | ||
| return 'status' in exception || 'error' in exception; |
There was a problem hiding this comment.
q: Are we dropping the status check on purpose?
There was a problem hiding this comment.
we could add it as an additional condition but don't think it's necessary
size-limit report 📦
|
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.
| // RpcException | ||
| if (typeof ex.getError === 'function' && typeof ex.initMessage === 'function') { | ||
| return true; |
There was a problem hiding this comment.
Duck-typing check may break for older NestJS versions
Medium Severity
The isExpectedError duck-typing relies on initMessage being a function on both HttpException and RpcException. The package's peerDependencies support @nestjs/common^8.0.0 || ^9.0.0, but initMessage appears to have been added as a public method in NestJS v10 (older documentation only lists getStatus and getResponse). If initMessage doesn't exist in v8/v9, isExpectedError would always return false, causing HttpException and RpcException to be incorrectly reported to Sentry. The existing nestjs-8 e2e test app has tests verifying these exceptions are NOT sent to Sentry, which would break.
Our conditions for dropping control flow errors were a bit broad, leading to silently dropping errors from being sent to Sentry including
axioserrors.Closes#19519