You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
✨ Apply consent to renderer execution contexts - #235
Keep renderer execution-context durations and identities consistent with consent while an Electron window remains open. Builds on the session and main-process lifecycle changes in #234.
Changes
Split execution contexts at consent boundaries and preserve terminal updates from granted periods.
Stop context events and periodic updates while consent is refused, while retaining window lifecycle listeners.
Resume live windows without reviving crashed or destroyed renderers; retain navigation readiness across consent and session changes.
These are Electron window execution contexts. Browser SDK event admission and replay collection are unchanged.
Test instructions
yarn exec vitest run --maxWorkers=2 — 1,374 tests passed across the complete stack.
Source TypeScript checks, changed-file lint and SDK build passed.
Coverage includes session renewal, terminal-event authorization, windows opened between sessions, destruction, and renderer crash/reload.
Checklist
Tested locally (playground)
Added unit tests for this change.
Added e2e/integration tests for this change.
Updated related documentation.
Agentic code review findings addressed or explicitly dismissed.
The consent handling for renderer execution contexts is in good shape and needs one round before merge. Open windows split on granted/pending, stop while refused, and resume without reviving a crashed or destroyed renderer, matching MainProcessContext. A renderer that becomes active during the sessionless gap still loses the granted period's terminal update when consent changes. This stays dormant until something calls TrackingConsentManager.update — this branch does not export that — so the rollout risk is that invariant, not a change to today's default.
Customer impact:High — With consent left at its initial granted value, renderer contexts behave as they do today. Once consent is updated on this manager, refusing it stops renderer execution-context reporting while the window stays open, and the last granted update is meant to stay in authorized storage.
Concern
Renderer execution-context lifetime across consent, session expiry, and crash reload
Risky
Quality — 3.5: The split, refusal, and resume paths are correct for a window already tracked in an active session, including crash reload and a synchronous renew after expiry. The tests match those paths and the architecture note matches the diff. One manager subscription, closePeriod, and the same early return MainProcessContext uses is a sound shape. What holds this below 5.0 is the sessionless gap: that early return assumes the previous period was already closed, and nothing covers a renderer that starts while the session is expired.
Review load — Focused (~30–45min): One risky boundary, the renderer execution-context lifetime, together with the consent and session ordering it depends on. The docs and unit tests sit on that same boundary.
Findings
[Minor] Gap-window consent change drops the granted terminal update — RendererProcessContexts.ts:295 returns once SESSION_RENEW has replaced a still-active gap context, and register() closes that context without emitting it. Emit the terminal update from register() before starting the replacement.
Renderer execution contexts now follow consent the same way the main process already does: a granted or pending change splits the open period, refusal stops context events and heartbeats, and a crashed or destroyed window stays closed when tracking resumes. Session renewal runs before the consent handler and the early return keeps that from rotating the window twice; the reload name stays unresolved until dom-ready even when consent or the session changes mid-reload. Approve. GitLab integration was still running when this was posted.
Customer impact:High — Execution contexts stay off unless enableExecutionContext is set, and consent still starts as granted. When both are in use, an open renderer window splits at each consent boundary and stops reporting while consent is refused.
Concern
Renderer execution contexts follow consent, including resume and reload naming
Risky
Quality — 5.0: The split, the refusal pause, and the crash or destroy veto are correct, including when session renewal has already started the new period. Tests cover delayed init, refusal, reload naming, and crash-after-expiry in proportion to that lifecycle. The architecture note matches the pause and the naming rule. The shape matches MainProcessContext and ViewCollection, so the next consent change has the same boundary to follow.
Review load — Focused (~15–45min): One risky boundary: renderer window lifetime against consent and session renewal, including the reload name guard. The doc and test updates sit on that same path.
The consent handling for renderer execution contexts is in good shape and needs one round before merge. Open windows split on granted/pending, stop while refused, and resume without reviving a crashed or destroyed renderer, matching MainProcessContext. A renderer that becomes active during the sessionless gap still loses the granted period's terminal update when consent changes. This stays dormant until something calls TrackingConsentManager.update — this branch does not export that — so the rollout risk is that invariant, not a change to today's default.
Customer impact:High — With consent left at its initial granted value, renderer contexts behave as they do today. Once consent is updated on this manager, refusing it stops renderer execution-context reporting while the window stays open, and the last granted update is meant to stay in authorized storage.
Concern
Renderer execution-context lifetime across consent, session expiry, and crash reload
Risky
Quality — 3.5: The split, refusal, and resume paths are correct for a window already tracked in an active session, including crash reload and a synchronous renew after expiry. The tests match those paths and the architecture note matches the diff. One manager subscription, closePeriod, and the same early return MainProcessContext uses is a sound shape. What holds this below 5.0 is the sessionless gap: that early return assumes the previous period was already closed, and nothing covers a renderer that starts while the session is expired.
Review load — Focused (~30–45min): One risky boundary, the renderer execution-context lifetime, together with the consent and session ordering it depends on. The docs and unit tests sit on that same boundary.
Findings
[Minor] Gap-window consent change drops the granted terminal update — RendererProcessContexts.ts:295 returns once SESSION_RENEW has replaced a still-active gap context, and register() closes that context without emitting it. Emit the terminal update from register() before starting the replacement.
Quality is 5.0. I would approve and merge this. Renderer execution contexts follow the same consent rules as the main process: a consent change closes the current period and, when the window is still alive and consent is granted or pending, starts the next period at that same timestamp. Listeners stay installed while consent is refused, so a later grant resumes a live page and leaves a crashed renderer stopped until its own reload. Navigation readiness sits on the window manager, so a consent or session change during a reload cannot freeze the pre-crash URL. enableExecutionContext still defaults off and consent still starts granted, so this reporting change applies only after both are turned on.
Customer impact:High — With execution contexts left disabled, or with consent left at its initial granted state, renderer reporting is unchanged. Enabling execution contexts and then refusing consent stops context events and heartbeats for windows that stay open; a granted period's final update stays authorized, and a crash is not revived by the grant alone.
Concern
Renderer execution-context consent lifecycle
Risky
Quality — 5.0: The consent, session, crash, and reload paths agree, including renew-before-consent so a period is not opened twice. The unit tests cover refusal, pending and granted splits, windows created while denied, and a reload whose name stays unresolved across those boundaries. The architecture notes match that behavior. The shape is sound: it matches MainProcessContext, where a session renewal may already have opened the new period and the consent handler leaves that period in place.
Review load — Focused (~30min–45min): One risky boundary: renderer context lifetime at consent changes, read together with session expiry and crash revival. The tests and architecture note are that same boundary.
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
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.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Motivation
Keep renderer execution-context durations and identities consistent with consent while an Electron window remains open. Builds on the session and main-process lifecycle changes in #234.
Changes
These are Electron window execution contexts. Browser SDK event admission and replay collection are unchanged.
Test instructions
yarn exec vitest run --maxWorkers=2— 1,374 tests passed across the complete stack.Checklist