-
-
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
feat(replay): Add a replay-specific logger #13256
Conversation
size-limit report 📦
|
Removes the old `logInfo` function and replaces it with a new replay-specific logger. Configuration is done when the replay integration is first initialized to avoid needing to pass around configuration options. This also means that we cannot select individual log statements to be added as breadcrumbs with `traceInternals` options. This also adds a `logger.exception` that wraps `captureException`. Note that only the following logging levels are supported: * info * log * warn * error With two additions: * exception * infoTick (needs a better name) - same as `info` but adds the breadcrumb in the next tick due to some pre-existing race conditions There are two configuration options: * enable(/disable)CaptureInternalExceptions * enable(/disable)TraceInternals
701d3ca
to
11415f5
Compare
@@ -192,7 +193,8 @@ function getResponseData( | |||
|
|||
return buildNetworkRequestOrResponse(headers, size, undefined); | |||
} catch (error) { | |||
DEBUG_BUILD && logger.warn('[Replay] Failed to serialize response body', error); | |||
DEBUG_BUILD && logger.warn('Failed to serialize response body'); |
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 think the one improvement we can do here more is to avoid having to double-call this in so many places. Instead, what about we make this something like this:
DEBUG_BUILD && logger.exception(error, 'Failed to serialize response body');
where the second argument is optional, and if defined will just logger.error
this string? This may safe a few more bytes, and IMHO is also nicer from a usage experience...?
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.
Updated, though it didn't seem to help bundle size too much
traceInternals: boolean; | ||
} | ||
|
||
/** JSDoc */ |
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.
/** JSDoc */ |
|
||
function _addBreadcrumb(message: unknown, level: SeverityLevel = 'info'): void { | ||
// Only support strings for breadcrumbs | ||
if (typeof message !== 'string') { |
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.
l: Do we need this check? IMHO we generally use this ourselves, worst case ${message}
will convert whatever it is to a string anyhow, which I guess is OK here...?
}); | ||
|
||
_logger.exception = (error: unknown, ...message: unknown[]) => { | ||
if (message && _logger.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.
can message
be empty here? I guess this always is at least an empty array, or is this not the case?
} else if (_trace) { | ||
// No need for a breadcrumb is `_capture` is enabled since it should be | ||
// captured as an exception | ||
_addBreadcrumb(error instanceof Error ? error.message : 'Unknown 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.
possibly we can skip this check, as Error
should be casted to a reasonable string automatically when we do ${message}
?
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.
left some comments for potential small bundle size improvements we can make, but overall I think this is good - better than before! So LGTM 🚀
Removes the old
logInfo
function and replaces it with a new replay-specificlogger. Configuration is done when the replay integration is first initialized
to avoid needing to pass around configuration options. This also means
that we cannot select individual log statements to be added as breadcrumbs with
traceInternals
options.This also adds a
logger.exception
that wrapscaptureException
.Note that only the following logging levels are supported:
info
log
warn
error
With two additions:
exception
infoTick
(needs a better name) - same asinfo
but adds the breadcrumb in the next tick due to some pre-existing race conditionsThere is one method to configure the logger:
setConfig({ traceInternals, captureExceptions })