feat(onboarding): bump SCM replay sample rate to 50%#114795
Merged
jaydgoss merged 1 commit intoMay 11, 2026
Merged
Conversation
Contributor
📊 Type Coverage Diff✅ No new type safety issues introduced. Coverage: 93.40% |
54f665a to
96213c3
Compare
ryan953
approved these changes
May 5, 2026
96213c3 to
0973d2c
Compare
Now that the integration actually registers during onboarding (the prior PR in this stack), bump the forced replay sample rate from 30% to 50%. We were previously seeing 0 tagged replays in production due to the init bug; with that fixed, 50% gives a faster signal on the funnel without doubling baseline replay storage.
0973d2c to
30c0dcb
Compare
eb6f2a8
into
jaygoss/replay-init-during-onboarding
67 checks passed
jaydgoss
added a commit
that referenced
this pull request
May 11, 2026
…114774) ## TL;DR Forced replays for SCM onboarding never start because the Replay integration isn't registered on `/onboarding/*` routes (those mount under `OrganizationContainerRoute`, not `OrganizationLayout`). Hoist `useReplayInit` to the App root so registration covers every route. ## Stack - **PR 1 (this):** fix Replay integration not registering during onboarding - [PR 2](#114795): bump sample rate to 50% ## Details The forced replay path for SCM onboarding (`useReplayForCriticalFlow` at `static/app/views/onboarding/onboarding.tsx:201`) is silently no-op'ing for SaaS users. The hook bails out when `Sentry.getReplay()` returns null, and during onboarding it always does: gsApp's `useReplayInit` was mounted inside `OrganizationHeader`, which only renders under `OrganizationLayout`. The onboarding routes use `OrganizationContainerRoute` instead, so the Replay integration was never registered. Recording only kicked in once the user navigated into the org, which matches the symptom we observed (no replays tagged `critical_flow:scm_onboarding` over 30d, and tag-less recordings starting after the user leaves `/onboarding/`). Move `useReplayInit` to the App root via a new `component:replay-init` hook. The new gsApp `ReplayInit` component is mounted in `App` (sibling of all route trees), so registration happens once and covers `OrganizationContainerRoute` and `OrganizationLayout` alike. `useReplayInit` no longer mounts under `OrganizationHeader`. Registration is async (dynamic import of `@sentry/react`), so on a fresh load straight into `/onboarding/welcome/` the consumer's effect can still fire before the integration resolves. To handle that without making the consumer drive init, `useReplayReady` is split out of `useReplayInit` — it subscribes to a module-level listener set that flips when registration completes. `useReplayForCriticalFlow` calls `useReplayReady` instead of `useReplayInit`, so the call site reads as "wait for Replay" rather than "redundantly initialize Replay." Per-mount sample gate switched from `useState` lazy-init to `useMemo` with empty deps; the value never updates, and `useMemo` signals that more clearly. Same sample rates pass through (`isStaff ? 1.0 : 0.05`, `1.0`), so behavior outside onboarding is unchanged. Self-hosted falls through to the OSS noop (no gsApp hook registered), matching the prior behavior that motivated 48ee2e9.
nikkikapadia
pushed a commit
that referenced
this pull request
May 12, 2026
…114774) ## TL;DR Forced replays for SCM onboarding never start because the Replay integration isn't registered on `/onboarding/*` routes (those mount under `OrganizationContainerRoute`, not `OrganizationLayout`). Hoist `useReplayInit` to the App root so registration covers every route. ## Stack - **PR 1 (this):** fix Replay integration not registering during onboarding - [PR 2](#114795): bump sample rate to 50% ## Details The forced replay path for SCM onboarding (`useReplayForCriticalFlow` at `static/app/views/onboarding/onboarding.tsx:201`) is silently no-op'ing for SaaS users. The hook bails out when `Sentry.getReplay()` returns null, and during onboarding it always does: gsApp's `useReplayInit` was mounted inside `OrganizationHeader`, which only renders under `OrganizationLayout`. The onboarding routes use `OrganizationContainerRoute` instead, so the Replay integration was never registered. Recording only kicked in once the user navigated into the org, which matches the symptom we observed (no replays tagged `critical_flow:scm_onboarding` over 30d, and tag-less recordings starting after the user leaves `/onboarding/`). Move `useReplayInit` to the App root via a new `component:replay-init` hook. The new gsApp `ReplayInit` component is mounted in `App` (sibling of all route trees), so registration happens once and covers `OrganizationContainerRoute` and `OrganizationLayout` alike. `useReplayInit` no longer mounts under `OrganizationHeader`. Registration is async (dynamic import of `@sentry/react`), so on a fresh load straight into `/onboarding/welcome/` the consumer's effect can still fire before the integration resolves. To handle that without making the consumer drive init, `useReplayReady` is split out of `useReplayInit` — it subscribes to a module-level listener set that flips when registration completes. `useReplayForCriticalFlow` calls `useReplayReady` instead of `useReplayInit`, so the call site reads as "wait for Replay" rather than "redundantly initialize Replay." Per-mount sample gate switched from `useState` lazy-init to `useMemo` with empty deps; the value never updates, and `useMemo` signals that more clearly. Same sample rates pass through (`isStaff ? 1.0 : 0.05`, `1.0`), so behavior outside onboarding is unchanged. Self-hosted falls through to the OSS noop (no gsApp hook registered), matching the prior behavior that motivated 48ee2e9.
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.
TL;DR
Bump the forced replay sample rate for SCM onboarding from 30% to 50%, now that replays actually start in this flow.
Stack
Details
The prior PR fixes the bug where the Replay integration wasn't registered on
/onboarding/*routes, so the 30%sampleRatewe configured was effectively 0%. With registration working, 50% gives a faster signal on the SCM onboarding funnel without doubling baseline replay storage. Easy to dial back if volume is too high.