Session replay: idle tabs still produce 2-3 day recordings under one session id on 1.425.1

[steadily-mondavarious]

Bug: idle tabs still produce multi-day recordings under one session id on 1.425.1

SDK: posthog-js 1.425.1 (npm), Next.js 16 pages router, US cloud, project 55682.

Expected: SESSION_LENGTH_LIMIT_MILLISECONDS (24 h) caps a recording. lazy-loaded-session-recorder.ts says the session check now runs in every idle state so that idle tabs no longer "accrete multi-day recordings that blew straight through SESSION_LENGTH_LIMIT under one session id".

Observed: tabs left open over a weekend keep shipping snapshot data under the same session id for 2 to 3 days, with near-zero active time. In the 7 days to 2026-09-07 13:30Z the project has 152 recordings spanning more than 86,400 s; 48 started after 1.425.1 reached production, and 15 of those carry only $lib_version = 1.425.1 events (so not a stale-bundle tab). Three examples, single SDK version 1.425.1 throughout:

session_id	first snapshot (UTC)	span	active
01a07916-11ad-7fa8-a71f-53152daa800a	2026-09-04 04:44:26	240,882 s (2.8 d)	0 s
01a07916-11a7-7c5c-8cc5-fb2ceb8cb25f	2026-09-04 12:28:26	213,042 s (2.5 d)	2 s
01a06939-3166-74ae-bd56-5d00aaa5d179	2026-09-03 21:42:31	170,694 s (2.0 d)	8 s

A fourth with real interaction: 01a068fe-0d49-720d-8725-c09c9de96ad7, first snapshot 2026-09-03 20:37:55, span 147,154 s, 471 s active, 104 events, all 1.425.1.

Measured with HogQL: min(min_first_timestamp), max(max_last_timestamp) and sum(active_milliseconds) grouped by session_id on raw_session_replay_events; SDK version from properties.$lib_version on the events sharing the $session_id.

Config that may matter: session_idle_timeout_seconds: 600, capture_pageview: false, capture_pageleave: true, session_recording.maskAllInputs: true, before_send: sampleByEvent(["$web_vitals"], 0.1). We also call sessionManager.resetSessionId() ourselves on route changes (feature flagged, live since 2026-09-03 18:40Z); the sessions above have no route changes in them, so that path was not involved.

Question: is the 24 h check expected to fire for a tab that emits no rrweb events at all while backgrounded (0 s active), or does it rely on the recorder receiving an event to run checkAndGetSessionAndWindowId? If the latter, the first event after wake-up appears to land on the old session id before rotation, extending max_last_timestamp past the cap.

[github-actions]

AI triage for #4825

Conclusion: Likely confirmed Session Replay idle/rotation bug with a specific event-ordering gap; it should not be closed as already fixed.
Confidence: 84%
Suggested labels: feature/replay, javascript, web, team/client-libraries

Thanks for the detailed session-level evidence. The 24-hour cap is not enforced by a dedicated wall-clock recorder timer: the recorder calls checkAndGetSessionAndWindowId() from its rrweb emit path. SessionIdManager also has an idle-timeout timer, but a backgrounded/frozen tab may not run that timer until it resumes.

There is a plausible ordering problem for the fully dormant case: _updateWindowAndSessionIds() first detects recorder idleness and calls _flushBuffer(), then performs the read-only session-manager check that enforces the 24-hour cap. That permits old-session buffered/lifecycle data to be flushed before rotation is adopted. The current regression test verifies that an already-confirmed-idle recorder rotates when it later receives a non-interactive event, but it does not assert that a tab whose idle transition is first observed after a long suspension cannot flush under the old ID.

1.427.3 includes the related replay fix in #4788, which resets the recorder idle clock after a rotation and prevents rotation-born recordings from being backdated. It is worth upgrading and checking newly started sessions, but that change alone does not prove this pre-rotation flush ordering is covered. Any fix here needs a focused suspended-tab regression test and careful volume monitoring, since rotation/flush changes can affect replay billing.

Investigation

• SessionIdManager.checkAndGetSessionAndWindowId() enforces SESSION_LENGTH_LIMIT_MILLISECONDS even for read-only calls, but it only runs when called; there is no separate 24-hour timer.
• The session manager does schedule an idle timeout at sessionTimeoutMs * 1.1, but browser tab suspension can delay that callback. Its forced-idle path resets the session and waits for a subsequent session-ID check before the recorder restarts.
• In _updateWindowAndSessionIds(), a non-interactive event observed after the recorder idle threshold sets _isIdle, emits sessionIdle, and calls _flushBuffer() before calling checkAndGetSessionAndWindowId(!isUserInteraction, event.timestamp).
• The current test titled rotates a confirmed-idle session at the 24 hour session cap, into a held epoch verifies that the recorder adopts a new session ID after a later non-interactive event, but does not verify that no old-session buffer was flushed before that check.
• The repository's replay incident guidance identifies this exact rotation/idle/flush area as a prior over-recording and multi-day-recording incident class; changes must preserve zero-upload behavior for untouched tabs and prevent flushing events beyond the session age cap.
• posthog-js 1.427.3 includes fix(replay): reset the idle clock before a rotation restart #4788, a related fix that resets the replay idle clock on session-ID rotation so a rotation-born recording does not start hours early. The reported version, 1.425.1, predates that release, but the changelog does not establish that fix(replay): reset the idle clock before a rotation restart #4788 fixes this flush-before-cap-check path.

Relevant files: packages/browser/src/extensions/replay/external/lazy-loaded-session-recorder.ts, packages/browser/src/sessionid.ts, packages/browser/src/__tests__/extensions/replay/lazy-sessionrecording.test.ts, packages/browser/src/__tests__/extensions/replay/lazy-sessionrecording-rotation-invariants.test.ts, packages/browser/CHANGELOG.md

Fix assessment

• Straightforward: no
• Risk: high
• Reason: The likely fault is localized, but changing the ordering of idle detection, lifecycle-marker routing, flushing, and session rotation is replay billing-sensitive. A fix must account for synchronous rrweb re-entry and preserve both old-session ending markers and held rotation-born buffers.

Pi session

The resumable JSONL pi session for this run was saved to a private gist: https://gist.github.com/marandaneto/62c31745aaed636bca006cdeb49635d7

Download it locally, then fork it into your own pi session:

pi --fork path/to/session.jsonl

Saved session:

• call-1-1-2026-09-07T13-33-33-014Z_01a07c12-f7d6-720a-b2e1-f5215c4e7295.jsonl

Close proposal

None. No issue close action was taken.

---

Generated by posthog-watcher-action using pi.