From da799e91298f8c2e73f11ccf80496b2bf254067c Mon Sep 17 00:00:00 2001 From: Francesco Novy Date: Wed, 26 Apr 2023 16:38:06 +0200 Subject: [PATCH] meta(changelog): Update Changelog for 7.50.0 --- CHANGELOG.md | 100 ++++++++++++++++++++++++++++++++++++++ packages/replay/README.md | 25 +++++++--- 2 files changed, 119 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2241d8cb8442..7c441a29b442 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,106 @@ - "You miss 100 percent of the chances you don't take. — Wayne Gretzky" — Michael Scott +## 7.50.0 + +### Important Changes + +- **doc(sveltekit): Promote the SDK to beta state (#7976)** + - feat(sveltekit): Convert `sentryHandle` to a factory function (#7975) + +With this release, the Sveltekit SDK ([@sentry/sveltekit](./packages/sveltekit/README.md)) is promoted to Beta. +This means that we do not expect any more breaking changes. + +The final breaking change is that `sentryHandle` is now a function. +So in order to update to 7.50.0, you have to update your `hooks.server.js` file: + +```js +// hooks.server.js + +// Old: +export const handle = sentryHandle; +// New: +export const handle = sentryHandle(); +``` + +- **feat(replay): Allow to configure URLs to capture network bodies/headers (#7953)** + +You can now capture request/response bodies & headers of network requests in Replay. +You have to define an allowlist of URLs you want to capture additional information for: + +```js +new Replay({ + networkDetailAllowUrls: ['https://sentry.io/api'], +}); +``` + +By default, we will capture request/response bodies, as well as the request/response headers `content-type`, `content-length` and `accept`. +You can configure this with some additional configuration: + +```js +new Replay({ + networkDetailAllowUrls: ['https://sentry.io/api'], + // opt-out of capturing bodies + networkCaptureBodies: false, + // These headers are captured _in addition to_ the default headers + networkRequestHeaders: ['X-Custom-Header'], + networkResponseHeaders: ['X-Custom-Header', 'X-Custom-Header-2'] +}); +``` + +Note that bodies will be truncated to a max length of ~150k characters. + +**- feat(replay): Changes of sampling behavior & public API** + - feat(replay): Change the behavior of error-based sampling (#7768) + - feat(replay): Change `flush()` API to record current event buffer (#7743) + - feat(replay): Change `stop()` to flush and remove current session (#7741) + +We have changed the behavior of error-based sampling, as well as adding & adjusting APIs a bit to be more aligned with expectations. +See [Sampling](./packages/replay/README.md#sampling) for details. + +We've also revamped some public APIs in order to be better aligned with expectations. See [Stoping & Starting Replays manually](./packages/replay/README.md#stopping--starting-replays-manually) for details. + +- **feat(core): Add multiplexed transport (#7926)** + +We added a new transport to support multiplexing. +With this, you can configure Sentry to send events to different DSNs, depending on a logic of your choosing: + +```js +import { makeMultiplexedTransport } from '@sentry/core'; +import { init, captureException, makeFetchTransport } from '@sentry/browser'; + +function dsnFromFeature({ getEvent }) { + const event = getEvent(); + switch(event?.tags?.feature) { + case 'cart': + return ['__CART_DSN__']; + case 'gallery': + return ['__GALLERY_DSN__']; + } + return [] +} + +init({ + dsn: '__FALLBACK_DSN__', + transport: makeMultiplexedTransport(makeFetchTransport, dsnFromFeature) +}); +``` + +### Additional Features and Fixes + +- feat(nextjs): Add `disableLogger` option that automatically tree shakes logger statements (#7908) +- feat(node): Make Undici a default integration. (#7967) +- feat(replay): Extend session idle time until expire to 15min (#7955) +- feat(tracing): Add `db.system` span data to DB spans (#7952) +- fix(core): Avoid crash when Function.prototype is frozen (#7899) +- fix(nextjs): Fix inject logic for Next.js 13.3.1 canary (#7921) +- fix(replay): Ensure console breadcrumb args are truncated (#7917) +- fix(replay): Ensure we do not set replayId on dsc if replay is disabled (#7939) +- fix(replay): Ensure we still truncate large bodies if they are failed JSON (#7923) +- fix(utils): default normalize() to a max. of 100 levels deep instead of Inifnity (#7957) + +Work in this release contributed by @Jack-Works. Thank you for your contribution! + ## 7.49.0 ### Important Changes diff --git a/packages/replay/README.md b/packages/replay/README.md index 8c0ea81e5cba..a790370c2d49 100644 --- a/packages/replay/README.md +++ b/packages/replay/README.md @@ -86,9 +86,9 @@ import * as Sentry from "@sentry/browser"; Sentry.setUser({ email: "jane.doe@example.com" }); ``` -### Stopping & re-starting replays +### Stopping & starting Replays manually -Replay recording only starts when it is included in the `integrations` array when calling `Sentry.init` or calling `addIntegration` from the a Sentry client instance. To stop recording you can call the `stop()`. +Replay recording only starts when it is included in the `integrations` array when calling `Sentry.init` or calling `addIntegration` from the a Sentry client instance. To stop recording you can call `stop()`. ```js import * as Sentry from "@sentry/react"; @@ -109,6 +109,16 @@ client?.addIntegration(replay); replay.stop(); ``` +When both `replaysSessionSampleRate` and `replaysOnErrorSampleRate` are `0`, recording will _not_ start. +In this case, you can manually start recording: + +```js +replay.start(); // Will start a session in "session" mode, regardless of sample rates +replay.startBuffering(); // Will start a session in "buffer" mode, regardless of sample rates +``` + + + ## Loading Replay as a CDN Bundle As an alternative to the NPM package, you can use Replay as a CDN bundle. @@ -154,8 +164,11 @@ Sampling allows you to control how much of your website's traffic will result in - `replaysSessionSampleRate` - The sample rate for replays that begin recording immediately and last the entirety of the user's session. - `replaysOnErrorSampleRate` - The sample rate for replays that are recorded when an error happens. This type of replay will record up to a minute of events prior to the error and continue recording until the session ends. -Sampling occurs when the session is first started. `replaysSessionSampleRate` is evaluated first. If it is sampled, then the replay recording begins. Otherwise, `replaysOnErrorSampleRate` is evaluated and if it is sampled, the integration will begin buffering the replay and will only upload a replay to Sentry when an error occurs. The remainder of the replay will behave similarly to a whole-session replay. - +When Replay is initialized, we check the `replaysSessionSampleRate`. +If it is sampled, then we start recording & sending Replay data immediately. +Else, if `replaysOnErrorSampleRate > 0`, we'll start recording in buffering mode. +In this mode, whenever an error occurs we'll check `replaysOnErrorSampleRate`. +If it is sampled, when we'll upload the Replay to Sentry and continue recording normally. ## Configuration @@ -234,5 +247,5 @@ This should not happen to often, but be aware that it is theoretically possible. ## Manually sending replay data You can use `replay.flush()` to immediately send all currently captured replay data. -This can be combined with `replaysOnErrorSampleRate: 1` -in order to be able to send the last 60 seconds of replay data on-demand. +When Replay is currently in buffering mode, this will send up to the last 60 seconds of replay data, +and also continue sending afterwards, similar to when an error happens & is recorded.