Skip to content

Commit a1a0475

Browse files
committed
change to use experiment
1 parent 63234ec commit a1a0475

File tree

3 files changed

+679
-20
lines changed

3 files changed

+679
-20
lines changed

packages/replay/src/types.ts

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -285,6 +285,7 @@ export interface ReplayPluginOptions extends ReplayNetworkOptions {
285285
scrollTimeout: number;
286286
ignoreSelectors: string[];
287287
};
288+
delayFlushOnCheckout: number;
288289
}>;
289290
}
290291

packages/replay/src/util/handleRecordingEmit.ts

Lines changed: 28 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -80,30 +80,38 @@ export function getHandleRecordingEmit(replay: ReplayContainer): RecordingEmitCa
8080
}
8181
}
8282

83+
const options = replay.getOptions();
84+
85+
// TODO: We want this as an experiment so that we can test
86+
// internally and create metrics before making this the default
87+
if (options._experiments.delayFlushOnCheckout) {
88+
// If the full snapshot is due to an initial load, we will not have
89+
// a previous session ID. In this case, we want to buffer events
90+
// for a set amount of time before flushing. This can help avoid
91+
// capturing replays of users that immediately close the window.
92+
setTimeout(() => replay.conditionalFlush(), options._experiments.delayFlushOnCheckout);
93+
94+
// Cancel any previously debounced flushes to ensure there are no [near]
95+
// simultaneous flushes happening. The latter request should be
96+
// insignificant in this case, so wait for additional user interaction to
97+
// trigger a new flush.
98+
//
99+
// This can happen because there's no guarantee that a recording event
100+
// happens first. e.g. a mouse click can happen and trigger a debounced
101+
// flush before the checkout.
102+
replay.cancelFlush();
103+
104+
return true;
105+
}
106+
83107
// Flush immediately so that we do not miss the first segment, otherwise
84108
// it can prevent loading on the UI. This will cause an increase in short
85109
// replays (e.g. opening and closing a tab quickly), but these can be
86110
// filtered on the UI.
87-
// if (replay.recordingMode === 'session') {
88-
// // We want to ensure the worker is ready, as otherwise we'd always send the first event uncompressed
89-
// void replay.flushImmediate();
90-
// }
91-
92-
// If the full snapshot is due to an initial load, we will not have
93-
// a previous session ID. In this case, we want to buffer events
94-
// for a set amount of time before flushing. This can help avoid
95-
// capturing replays of users that immediately close the window.
96-
setTimeout(() => replay.conditionalFlush(), replay.getOptions().flushMinDelay);
97-
98-
// Cancel any previously debounced flushes to ensure there are no [near]
99-
// simultaneous flushes happening. The latter request should be
100-
// insignificant in this case, so wait for additional user interaction to
101-
// trigger a new flush.
102-
//
103-
// This can happen because there's no guarantee that a recording event
104-
// happens first. e.g. a mouse click can happen and trigger a debounced
105-
// flush before the checkout.
106-
replay.cancelFlush();
111+
if (replay.recordingMode === 'session') {
112+
// We want to ensure the worker is ready, as otherwise we'd always send the first event uncompressed
113+
void replay.flushImmediate();
114+
}
107115

108116
return true;
109117
});

0 commit comments

Comments
 (0)