fix(session-replay-browser): Optimize function restart logic

[jpollock-ampl]

Summary

This PR optimizes some of the logic around starting/restarting replay capture.

Previously, the following three actions would cause the replay to start or restart:

• Focus Change
  • This is desired, we want to restart when this happens
• Session ID Changes (via setSessionId())
  • This is desired, we want to restart when this happens
• An event being emitted from the SDK
  • Undesired, a restart is unnecessary in this scenario

This PR stops the replay capture from being restarted when an event is emitted from the SDK.

How does this fix work?

The primary change is in recordEvents():

if (this.recordCancelCallback && !forceRestart) { 
  // Exit Early
}

We will check for an existing callback and if the user does not pass forceRestart (default is forceRestart=false), we will exit early and not re-create the SDK.

In the case of "focus" or "session ID changes", we pass forceRestart=true, to ensure that a new capture is created.

Verification

Beyond unit tests, I created a test app and installed this version of the SDK. I was able to observe the behavior of the SDK on a focus event and then when sending 5 events via a button click:

The first 3 logs represent the "focus" event. The fourth log represents the button click.

---

Notes:

Given a call to track() in your application, it goes through the Amplitude Analytics SDK's pipeline:

For us, that means the plugin execution pipeline. So it goes through timeline.ts, which executes the various types of plugins:

• before plugins
• enrichment plugins (this is what our plugin is)
• destination plugins

Our plugin (the SR plugin) is an enrichment plugin (source), so its execute() method is called for every single event (source)

The execute() method calls:

• evaluateTargetingAndCapture, which will evaluate targeting conditions (source code for evaluateTargetingAndCapture)
• It then calls await this.recordEvents() (if not during initialization)
• OR calls void this.initialize(true) during initialization, which also calls recordEvents()

The recordEvents() method:

• Calls this.getShouldRecord() to determine if recording should happen
• If yes, starts the rrweb capture process (including tearing down the existing instance via stopRecordingEvents())

Checklist

• Does your PR title have the correct title format?
• Does your PR have a breaking change?:

[jxiwang]

Nice! Thanks for adding this!

[lewgordon-amplitude]

LGTM!

[lewgordon-amplitude]

Nit: Maybe instead of "Exiting" we could say "not restarting". I wouldn't want this to leak to users who made get the wrong impression.

[jpollock-ampl]

Thank you for the feedback - c81dab9

[lewgordon-amplitude]

I was thinking these could be non null since their defaults may not be obvious and maybe it's better to be more explicit here. It also saves a null check.

Suggested change

	async recordEvents(recordEventsConfig?: { shouldLogMetadata?: boolean; forceRestart?: boolean }) {
	const { shouldLogMetadata = true, forceRestart = true } = recordEventsConfig || {};
	async recordEvents({shouldLogMetadata, forceRestart}: { shouldLogMetadata: boolean; forceRestart: boolean }) {

[jpollock-ampl]

Great call - f75a512

[lewgordon-amplitude]

Minor nit: Maybe we should include the session replay ID or session ID? I think it wouldn't hurt and would potentially help with debugging.

[jpollock-ampl]

Done! c68312f

[lewgordon-amplitude]

LGTM!