Skip to content

Commit e65c142

Browse files
committed
change to use experiment
1 parent b7e7a01 commit e65c142

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
@@ -269,6 +269,7 @@ export interface ReplayPluginOptions extends ReplayNetworkOptions {
269269
traceInternals: boolean;
270270
mutationLimit: number;
271271
mutationBreadcrumbLimit: number;
272+
delayFlushOnCheckout: number;
272273
}>;
273274
}
274275

packages/replay/src/util/handleRecordingEmit.ts

Lines changed: 28 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -71,30 +71,38 @@ export function getHandleRecordingEmit(replay: ReplayContainer): RecordingEmitCa
7171
}
7272
}
7373

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

99107
return true;
100108
});

0 commit comments

Comments
 (0)