fix(core): Suppress stack when SentryError
isn't an error
#5562
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We use
SentryError
s in our event processing and sending pipeline both when something has gone legitimately wrong and when we just want to bail on a promise chain. In all cases, however, we log both the message and the stack, at a warning log level, which both clutters the logs and unnecessarily alarms anyone who has logging on.This fixes that by adding a
logLevel
property to theSentryError
class, which can be read before we log to the console. The default behavior remains the same (log the full error, usinglogger.warn
), but now we have the option of passing'log'
as a second constructor parameter, in order to mark a givenSentryError
as something which should only belogger.log
ged and whose stack should be suppressed.(To answer the inevitable Why now? question, it's because it was making my test app logs really hard to read and it finally drove me one banana too far.)