Skip to content

Commit 1dd72bd

Browse files
committed
streamline changelog & update replay readme
1 parent 93cf761 commit 1dd72bd

File tree

2 files changed

+27
-51
lines changed

2 files changed

+27
-51
lines changed

CHANGELOG.md

Lines changed: 8 additions & 45 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@
1010

1111
- **doc(sveltekit): Promote the SDK to beta state (#7874)**
1212

13-
The SvelteKit SDK (@sentry/sveltekit) is now officially in Beta.
13+
The SvelteKit SDK ([@sentry/sveltekit](./packages/sveltekit/README.md)) is now officially in Beta.
1414
This means that we do not expect any breaking changes anymore.
1515

1616
- **feat(replay): Allow to configure URLs to capture network bodies/headers (#7953)**
@@ -40,44 +40,15 @@ new Replay({
4040

4141
Note that bodies will be truncated to a max length of ~150k characters.
4242

43-
**- feat(replay): Extend session idle time until expire to 15min (#7955)**
44-
45-
Replay Sessions will now only be refreshed when a user is idle for 15min or more.
46-
Previously, we would consider 5min of idle time as the threshold for this, which sometimes resulted in a lot of consequitive sessions.
47-
48-
**- feat(replay): Change the behavior of error-based sampling (#7768)**
49-
50-
We have changed the behavior of error-based sampling, as well as adding & adjusting APIs a bit to be more aligned with expectations.
51-
52-
First, the `replaysOnErrorSampleRate` will now be applied per-error at error-time, not in advance at session creation time -
53-
so the sampling rate was not accurate if you had sessions with many errors.
54-
Now whenever an error happens, we'll check the error sample rate, and potentially flush the session.
55-
56-
Related to this, we also reworked the public `start()` method and added a new `startBuffering()` method.
57-
58-
When calling `start()`, it will now _always_ start a session-based Replay, ignoring sample rates.
59-
Note that it will throw an error if a session is already running.
60-
61-
You can use the new `startBuffering()` method to start a new Replay in buffering-mode.
62-
This will either wait for an error (when `replaysOnErrorSampleRate > 0`), or until you manually call `replay.flush()`.
63-
64-
Note that with this change, as soon as either `replaysSessionSampleRate` or `replaysOnErrorSampleRate` are `> 0`,
65-
we will _always_ start recording in the background, either in session mode or in buffering mode.
66-
When both sample rates are set to `0`, you can manually start the session with either `replay.start()` or `replay.startBuffering()`.
67-
68-
69-
**- Improved Replay `flush()` & `stop()` APIs**
43+
**- feat(replay): Changes of sampling behavior & public API**
44+
- feat(replay): Change the behavior of error-based sampling (#7768)
7045
- feat(replay): Change `flush()` API to record current event buffer (#7743)
7146
- feat(replay): Change `stop()` to flush and remove current session (#7741)
7247

73-
We have revamped some existing public API of Replay in order to be better aligned with expectations.
74-
75-
`replay.flush()` now works differently when in error sampling mode:
76-
It will send the buffered replay data, then convert the session to a "regular" session and continue recording.
77-
With this, you can manually start capturing at any point.
48+
We have changed the behavior of error-based sampling, as well as adding & adjusting APIs a bit to be more aligned with expectations.
49+
See [Sampling](./packages/replay/README.md#sampling) for details.
7850

79-
`replay.stop()` will now flush the event buffer before stopping, and remove the session from session storage.
80-
This also means that `stop()` now returns a promise.
51+
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.
8152

8253
- **feat(core): Add multiplexed transport (#7926)**
8354

@@ -105,25 +76,17 @@ init({
10576
});
10677
```
10778
108-
- **fix(core): fix(utils): default normalize() to a max. of 100 levels deep instead of Inifnity (#7957)**
109-
110-
We used to default to normalize objects to a depth of `Infinity`.
111-
For most cases, this shouldn't matter, because objects aren't actually infinitely deep, and we handle circular dependencies reasonably well.
112-
However, we found out that there _are_ cases where we can still end up running into an infinitely deep recursion -
113-
for example, when using dynamicly generated proxies, which we cannot detect as "same instance", thus our circular dependency handling breaks down.
114-
115-
In order to account for these cases, we now default `normalize()` to a max. depth of 100.
116-
This should avoid this crashing when, for whatever reason, circular dependencies are not properly detected.
117-
11879
### Additional Features and Fixes
11980
12081
- feat(nextjs): Add `disableLogger` option that automatically tree shakes logger statements (#7908)
82+
- feat(replay): Extend session idle time until expire to 15min (#7955)
12183
- feat(tracing): Add `db.system` span data to DB spans (#7952)
12284
- fix(core): Avoid crash when Function.prototype is frozen (#7899)
12385
- fix(nextjs): Fix inject logic for Next.js 13.3.1 canary (#7921)
12486
- fix(replay): Ensure console breadcrumb args are truncated (#7917)
12587
- fix(replay): Ensure we do not set replayId on dsc if replay is disabled (#7939)
12688
- fix(replay): Ensure we still truncate large bodies if they are failed JSON (#7923)
89+
- fix(utils): default normalize() to a max. of 100 levels deep instead of Inifnity (#7957)
12790
12891
## 7.49.0
12992

packages/replay/README.md

Lines changed: 19 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -86,9 +86,9 @@ import * as Sentry from "@sentry/browser";
8686
Sentry.setUser({ email: "[email protected]" });
8787
```
8888
89-
### Stopping & re-starting replays
89+
### Stopping & starting Replays manually
9090
91-
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()`.
91+
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()`.
9292
9393
```js
9494
import * as Sentry from "@sentry/react";
@@ -109,6 +109,16 @@ client?.addIntegration(replay);
109109
replay.stop();
110110
```
111111
112+
When both `replaysSessionSampleRate` and `replaysOnErrorSampleRate` are `0`, recording will _not_ start.
113+
In this case, you can manually start recording:
114+
115+
```js
116+
replay.start(); // Will start a session in "session" mode, regardless of sample rates
117+
replay.startBuffering(); // Will start a session in "buffer" mode, regardless of sample rates
118+
```
119+
120+
121+
112122
## Loading Replay as a CDN Bundle
113123
114124
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
154164
- `replaysSessionSampleRate` - The sample rate for replays that begin recording immediately and last the entirety of the user's session.
155165
- `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.
156166
157-
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.
158-
167+
When Replay is initialized, we check the `replaysSessionSampleRate`.
168+
If it is sampled, then we start recording & sending Replay data immediately.
169+
Else, if `replaysOnErrorSampleRate > 0`, we'll start recording in buffering mode.
170+
In this mode, whenever an error occurs we'll check `replaysOnErrorSampleRate`.
171+
If it is sampled, when we'll upload the Replay to Sentry and continue recording normally.
159172
160173
## Configuration
161174
@@ -234,5 +247,5 @@ This should not happen to often, but be aware that it is theoretically possible.
234247
## Manually sending replay data
235248
236249
You can use `replay.flush()` to immediately send all currently captured replay data.
237-
This can be combined with `replaysOnErrorSampleRate: 1`
238-
in order to be able to send the last 60 seconds of replay data on-demand.
250+
When Replay is currently in buffering mode, this will send up to the last 60 seconds of replay data,
251+
and also continue sending afterwards, similar to when an error happens & is recorded.

0 commit comments

Comments
 (0)