-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
ref(core): Avoid using SentryError
for event processing control flow
#15823
Conversation
size-limit report 📦
|
packages/core/src/client.ts
Outdated
function isInternalError(error: unknown): error is InternalError { | ||
return !!error && typeof error === 'object' && INTERNAL_ERROR_SYMBOL in error; | ||
} | ||
|
||
function isDoNotSendEventError(error: unknown): error is DoNotSendEventError { | ||
return !!error && typeof error === 'object' && DO_NOT_SEND_EVENT_SYMBOL in error; | ||
} |
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.
Although we want to differentiate them, we can use a single isX
method for now given everything checks for both:
function isClientProcessingError(error: unknown): error is InternalError | DoNotSendEventError {
return !!error && typeof error === 'object' && (INTERNAL_ERROR_SYMBOL in error || DO_NOT_SEND_EVENT_SYMBOL in error);
}
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.
actually it is not entirely the same, today we differentiate based on this if we do logger.log
or logger.warn
. Not sure how important that is to us though 🤔
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.
I guess we can keep them separate for now then.
be83d3f
to
19c86a4
Compare
8fe61d1
to
08a50f1
Compare
This PR replaces our usage of
SentryError
for control flow in our event processing.Instead, we now throw either an
InternalError
orDoNotSendEventError
(which are just POJOs with a symbol, without a stackframe). These two also allow us to differentiate between these two use cases, which so far have been kind of combined via the log level, but are really different things - one is "expected"/configured by a user, the other is unexpected and more of a warning.I also removed the handling for
SentryError
from inbound filters, as this should then become unused.This also deprecates
SentryError
, it is no longer used and we can eventually remove it.ref #15725 (comment)