fix(studio): dedupe repeated selection telemetry - #3498
Conversation
miguel-heygen
left a comment
There was a problem hiding this comment.
Reviewed at exact head e746e41be66356db224f3d4916fd3667616f9b14.
Code audit: read all five changed files and enumerated every applyDomSelection, setRightPanelTab, and studio:tab_switch site. The same-target guard runs before selection/timeline state mutation, but still reveals the inspector; preserveGroup refreshes remain additive to metadata; Variables stays in place. The panel refs make same-render-batch calls compare against the latest requested tab/pane rather than stale React state, so a real flat-inspector Layers→Design reveal emits once while repeated calls emit zero.
Verification: full repository build passed. The five focused Studio files passed 53/53 tests; Studio typecheck, Oxfmt check, and Oxlint passed. All hosted exact-head checks are green.
Runtime — synthetic local Studio PR build: a fixture composition selected #headline through the documented window.__studioTest hook. The first selection produced one /api/projects/qa3498/selection PUT; 100 sequential same-target selections produced zero additional PUTs. With the flat inspector showing Layers, two repeated selections restored Design and still produced zero selection PUTs. No page errors were reported. This validates client selection/panel behavior only; no production data or PostHog project configuration was touched.
Non-blocking existing asymmetry: direct Design/Layers button changes go through setExclusiveRightInspectorPane and still do not emit tab_switch; this PR correctly dedupes and restores the setRightPanelTab path that caused the storm, but it does not make direct pane-click analytics complete.
Verdict: APPROVE
Reasoning: The state guard removes the high-volume loop without suppressing explicit refreshes or inspector restoration, and code, focused tests, hosted CI, and the live Studio witness agree.
— Magi
What
studio:tab_switchonly when the right-panel tab or visible inspector pane actually changes.useDomSelectiontype contract into a focused module so the hook remains within the repository's file-size limit.Why
A single Studio installation repeatedly selected the same target and reopened the already-active Design tab. Each pass recreated selection state, republished it, and emitted another
studio:tab_switch, producing millions of events for one PostHog distinct ID and triggering PostHog's high-volume-ID protection.The redundant state churn also amplified
studio:studio_selection_publish_failedwhen the local Studio selection endpoint was unavailable.This is a product-side event loop. No PostHog project configuration change is required; person processing should remain enabled for these real installation-scoped events.
How
designbut the flat inspector currently shows Layers.preserveGrouprefreshes through so changed selection metadata is not hidden.Test plan
Verified on current
origin/main:Additional suite evidence: a prior full Studio run passed 4,467 tests and reported 11 load-sensitive failures in two unrelated test files; both files then passed independently (27/27).