Skip to content

feat(onboarding): bump SCM replay sample rate to 50%#114795

Merged
jaydgoss merged 1 commit into
jaygoss/replay-init-during-onboardingfrom
jaygoss/scm-onboarding-replay-bump-sample-rate
May 11, 2026
Merged

feat(onboarding): bump SCM replay sample rate to 50%#114795
jaydgoss merged 1 commit into
jaygoss/replay-init-during-onboardingfrom
jaygoss/scm-onboarding-replay-bump-sample-rate

Conversation

@jaydgoss
Copy link
Copy Markdown
Member

@jaydgoss jaydgoss commented May 4, 2026

TL;DR

Bump the forced replay sample rate for SCM onboarding from 30% to 50%, now that replays actually start in this flow.

Stack

  • PR 1: fix Replay integration not registering during onboarding
  • PR 2 (this): bump sample rate to 50%

Details

The prior PR fixes the bug where the Replay integration wasn't registered on /onboarding/* routes, so the 30% sampleRate we 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.

@github-actions github-actions Bot added the Scope: Frontend Automatically applied to PRs that change frontend components label May 4, 2026
@jaydgoss jaydgoss marked this pull request as ready for review May 4, 2026 22:36
@jaydgoss jaydgoss requested a review from a team as a code owner May 4, 2026 22:36
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 4, 2026

📊 Type Coverage Diff

✅ No new type safety issues introduced. Coverage: 93.40%

@jaydgoss jaydgoss requested a review from a team May 4, 2026 22:42
@jaydgoss jaydgoss force-pushed the jaygoss/scm-onboarding-replay-bump-sample-rate branch from 54f665a to 96213c3 Compare May 5, 2026 17:13
@jaydgoss jaydgoss force-pushed the jaygoss/scm-onboarding-replay-bump-sample-rate branch from 96213c3 to 0973d2c Compare May 11, 2026 16:04
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.
@jaydgoss jaydgoss force-pushed the jaygoss/scm-onboarding-replay-bump-sample-rate branch from 0973d2c to 30c0dcb Compare May 11, 2026 16:27
@jaydgoss jaydgoss merged commit eb6f2a8 into jaygoss/replay-init-during-onboarding May 11, 2026
67 checks passed
@jaydgoss jaydgoss deleted the jaygoss/scm-onboarding-replay-bump-sample-rate branch May 11, 2026 17:15
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Frontend Automatically applied to PRs that change frontend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants