fix(sessions): keep streaming live when the window is backgrounded#3116
Draft
posthog[bot] wants to merge 1 commit into
Draft
fix(sessions): keep streaming live when the window is backgrounded#3116posthog[bot] wants to merge 1 commit into
posthog[bot] wants to merge 1 commit into
Conversation
Streamed agent events are committed to the conversation store via a short setTimeout flush in the renderer. Chromium clamps and (when the window is occluded/hidden) freezes renderer timers, so while the app is backgrounded that flush never runs: streamed events pile up unflushed and only render in a burst when the timer thaws on refocus. This is why a waiting/looping agent appears to hang and its messages all appear at once after the user sends a follow-up. Set backgroundThrottling: false on the main window so renderer timers keep running at full speed while backgrounded, letting live streaming flow during long-running agent runs. Generated-By: PostHog Code Task-Id: d38d3951-6357-4d57-809c-74d47581a163
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When the agent enters a waiting/looping state (e.g. "Loop over this PR until all checks succeed" → "I'll check back in ~10 min once CI finishes"), the conversation appears to hang. The messages the agent produces afterward stay hidden and then appear all at once the moment the user sends a follow-up.
The streamed events are not lost — they are buffered in the renderer and committed to the conversation store on a short
setTimeoutflush (a frame-sized coalescing window that keeps streaming from re-rendering per token). Chromium clamps, and once the window is occluded/hidden effectively freezes, renderer timers when the window is backgrounded. Backgrounding the app is exactly what you do during a 10-minute CI wait, so the flush timer stops firing: buffered events pile up and only drain in a burst when the timer thaws on refocus (sending a follow-up focuses the window). This matches the reported "hidden messages appear the instant a follow-up is sent."Changes
Set
backgroundThrottling: falseon the mainBrowserWindowso the renderer keeps running at full speed while backgrounded. This keeps the streamed-event flush (and other timer/rAF-driven UI) working during long-running agent runs, so a waiting/looping agent no longer looks hung.How did you test this?
I traced the full local streaming path (agent stream tap → tRPC subscription → renderer flush → zustand store → conversation view) and confirmed the only deferral point is the renderer
setTimeoutflush inSessionService; every other hop delivers immediately.backgroundThrottlingwas unset (defaults totrue), andSessionService(which owns the flush) is bound in the renderer container, so the flush timer is subject to Chromium background throttling — the mechanism behind the symptom.I was not able to run the live multi-minute backgrounded repro in this headless environment, so this has not been verified end-to-end in a running app; the fix is the standard Electron remedy for a backgrounded renderer batching updates until refocus.
Automatic notifications
Created with PostHog Code from an inbox report.