Skip to content
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

Merged
merged 8 commits into from
Aug 12, 2024
Merged

Conversation

billyvg
Copy link
Member

@billyvg billyvg commented Aug 6, 2024

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 is one method to configure the logger:

  • setConfig({ traceInternals, captureExceptions })

Copy link
Contributor

github-actions bot commented Aug 6, 2024

size-limit report 📦

Path Size
@sentry/browser 22.5 KB (0%)
@sentry/browser (incl. Tracing) 34.29 KB (0%)
@sentry/browser (incl. Tracing, Replay) 70.51 KB (+0.24% 🔺)
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags 63.82 KB (+0.23% 🔺)
@sentry/browser (incl. Tracing, Replay with Canvas) 74.91 KB (+0.22% 🔺)
@sentry/browser (incl. Tracing, Replay, Feedback) 87.53 KB (+0.2% 🔺)
@sentry/browser (incl. Tracing, Replay, Feedback, metrics) 89.35 KB (+0.18% 🔺)
@sentry/browser (incl. metrics) 26.81 KB (0%)
@sentry/browser (incl. Feedback) 39.46 KB (0%)
@sentry/browser (incl. sendFeedback) 27.13 KB (0%)
@sentry/browser (incl. FeedbackAsync) 31.79 KB (0%)
@sentry/react 25.26 KB (0%)
@sentry/react (incl. Tracing) 37.28 KB (0%)
@sentry/vue 26.65 KB (0%)
@sentry/vue (incl. Tracing) 36.13 KB (0%)
@sentry/svelte 22.63 KB (0%)
CDN Bundle 23.73 KB (0%)
CDN Bundle (incl. Tracing) 35.96 KB (0%)
CDN Bundle (incl. Tracing, Replay) 70.34 KB (-0.09% 🔽)
CDN Bundle (incl. Tracing, Replay, Feedback) 75.59 KB (-0.08% 🔽)
CDN Bundle - uncompressed 69.58 KB (0%)
CDN Bundle (incl. Tracing) - uncompressed 106.52 KB (0%)
CDN Bundle (incl. Tracing, Replay) - uncompressed 218.02 KB (-0.16% 🔽)
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 230.91 KB (-0.15% 🔽)
@sentry/nextjs (client) 37.14 KB (0%)
@sentry/sveltekit (client) 34.85 KB (0%)
@sentry/node 115.61 KB (0%)
@sentry/node - without tracing 90 KB (-0.01% 🔽)
@sentry/aws-serverless 99.42 KB (0%)

billyvg added 3 commits August 7, 2024 11:51
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
@billyvg billyvg force-pushed the feat-replay-replay-logger branch from 701d3ca to 11415f5 Compare August 7, 2024 16:33
@@ -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');
Copy link
Member

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...?

Copy link
Member Author

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

@billyvg billyvg marked this pull request as ready for review August 8, 2024 21:12
@billyvg billyvg requested a review from a team as a code owner August 8, 2024 21:12
@billyvg billyvg requested a review from mydea August 9, 2024 20:37
traceInternals: boolean;
}

/** JSDoc */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/** JSDoc */


function _addBreadcrumb(message: unknown, level: SeverityLevel = 'info'): void {
// Only support strings for breadcrumbs
if (typeof message !== 'string') {
Copy link
Member

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) {
Copy link
Member

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');
Copy link
Member

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}?

Copy link
Member

@mydea mydea left a 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 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants