Summary

rrweb session-replay recording could stop entirely while the rest of the Replay integration kept working — breadcrumbs, network, and console events continued and segments kept flushing, so it looked like "recording just froze." This makes recording resilient so a single transient failure can no longer permanently kill it.

Root cause

Every rrweb event type flows through the single getHandleRecordingEmit callback, which had no try/catch. Because Sentry's rrweb errorHandler returns undefined, rrweb re-throws any error that escapes the callback (callbackWrapper), which can tear down recording or leave the mutation buffer permanently locked.

Separately, the buffer→session conversion (sendBufferedReplayOrFlush) tears down rrweb and restarts it. If that restart failed — rrweb's own record() swallows internal errors and returns undefined, and startRecording() swallowed throws — _stopRecording was left unset with no recovery while _isEnabled stayed true. Result: all rrweb stops, breadcrumbs keep flowing.

Changes

• handleRecordingEmit.ts: wrap the emit callback body in try/catch → handleException; never let an exception escape back into rrweb.
• replay.ts startRecording(): detect a missing recorder (record() threw or returned undefined), surface it, and track a bounded failure count.
• replay.ts: add _ensureRecordingIsRunning(), a flush-time watchdog that restarts a recorder which died while the integration is enabled and unpaused (bounded to avoid hot-looping).

Includes unit + integration tests, including a real-rrweb reproduction, covering the escape, the recovery, and the retry bound.

Follow-up

A separate fix in the @sentry-internal/rrweb fork (wrap takeFullSnapshot's lock/unlock in try/finally, and unlock on the !node early-return) will close the "stuck locked" hazard at the source.

🤖 Generated with Claude Code