fix: guard executor shutdown in BaseCaptureStrategy.stop()

[tsushanth]

Fixes #5564

Problem

Each ReplayIntegration.start() constructs a fresh SessionCaptureStrategy or BufferCaptureStrategy. Both inherit BaseCaptureStrategy, which owns a persistingExecutor that was previously declared as a Kotlin lazy delegate.

stop() resets the delegated properties segmentTimestamp and currentReplayId. Their setters call runInBackground, which — when options.threadChecker.isMainThread() is true — accesses persistingExecutor, silently initialising the lazy. stop() never shuts the executor down, so one SentryReplayPersister-* thread is abandoned on every cycle. Kiln benchmark data confirmed monotonically growing thread counts and a GC allocation rate roughly 9× baseline after the repeated start/stop pattern introduced in kiln#73.

Fix

Replace the lazy delegate with an explicit nullable holder (persistingExecutorHolder). The custom get() mirrors the old lazy behaviour (create-on-first-access) while making initialisation detectable. At the end of stop(), if the holder is non-null the executor is shut down via shutdownNow() — non-blocking, safe to call on the main thread — and the holder is cleared so a subsequent start() gets a fresh executor without any residual state.

ReplayExecutorService.shutdown() is intentionally not used here: it blocks for options.shutdownTimeoutMillis and risks an ANR when invoked on the main thread. shutdownNow() interrupts any in-flight persistence write and discards the queue, which is acceptable because cache.close() is called immediately before in the same stop() body.

Test

Added stop shuts down persisting executor so no SentryReplayPersister threads leak across cycles to SessionCaptureStrategyTest. The test stubs threadChecker.isMainThread() to true (forcing the persisting executor path), runs three start/stop cycles, and asserts that no SentryReplayPersister-* threads remain alive after a short drain window.

[runningcode]

Thanks for contributing, could you run spotlessApply to fix the formatting failure? Then we'll review this more closely.

[romtsn]

@tsushanth thanks for your contribution, that's very much appreciated! I'm thinking if there's potentially a better approach, which would be to pull persistingExecutor up to the ReplayIntegration level and then pass it as a ctor argument to the respective CaptureStrategy.

It could then have the same lifecycle as the replayExecutor (that is, shut it down inside ReplayIntegration.close()) and would survive multiple start/stop calls, potentially saving us the cost of creating a new executor every time we start a new recording.

[tsushanth]

Refactored per the feedback — persistingExecutor is now owned by ReplayIntegration instead of BaseCaptureStrategy:

• Declared as a lazy field in ReplayIntegration using the same pattern as replayExecutor (thread factory moved there too)
• Passed as a constructor argument to SessionCaptureStrategy and BufferCaptureStrategy, which forward it up to BaseCaptureStrategy
• BufferCaptureStrategy.convert() hands both executors to the new SessionCaptureStrategy to preserve ordering
• ReplayIntegration.close() shuts down persistingExecutor alongside replayExecutor
• BaseCaptureStrategy.stop() no longer touches the executor — the holder/lazy workaround and per-stop shutdown are gone

Tests updated to pass a mock persistingExecutor matching the existing mock pattern.

[tsushanth]

Refactored as suggested @romtsn — persistingExecutor is now owned by ReplayIntegration and passed as a constructor argument to the capture strategies. It shares the same lifecycle as replayExecutor: created lazily on first use, survives stop()/start() cycles, and shut down in ReplayIntegration.close().

Also ran spotlessApply to fix the formatting failure @runningcode flagged.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6d4e33b. Configure here.}