[Sentry: APP-HT5] Web onboarding private-domain step loops history.replaceState past Safari's rate limit

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-HT5

Impact (snapshot at filing)

• Users (total since first seen): 22
• Events: 38
• Users (last 7d, in 9.4.44–9.4.46): 2
• First seen: 2026-07-16
• Last seen: ongoing (events today)
• Platform: web — Mobile Safari (iOS 18.7) observed; Safari rate limit is what surfaces it
• App version(s): 9.4.45-14 and others in range
• Affected route(s): /onboarding/private-domain
• View name: Onboarding_Private_Domain
• Mechanism: auto.browser.global_handlers.onunhandledrejection
• DOMException.code: 18 (SecurityError)

Error

SecurityError: Attempt to use history.replaceState() more than 100 times per 10 seconds

Stack trace (top frames, first-party only)

../node_modules/@react-navigation/native/lib/module/useLinking.js:373:24 (onStateChange)
        history.replace({
../node_modules/@react-navigation/native/lib/module/createMemoryHistory.js:128:34 (<object>.replace)
      window.history.replaceState({
[native code] (replaceState)

Suspected cause

A navigation-state loop on the onboarding private-domain step. Something re-dispatches navigation on
every state change — a redirect effect whose dependency changes each render, or a
navigate/setParams call in an effect that itself re-triggers the effect — so react-navigation's
useLinking onStateChange fires history.replace repeatedly. Safari caps replaceState at 100
calls per 10 seconds and throws once the loop exceeds it.

The rate limit is the symptom, not the bug: the underlying problem is an unbounded navigation loop
that will also burn CPU and block the onboarding flow on browsers without a cap.

Worth auditing the redirect logic on the private-domain onboarding screen for an effect that
navigates without a guard on the current route/state.

Reproduction

Unknown — see Sentry events linked above. Reaching /onboarding/private-domain (sign up with a
private email domain and proceed through onboarding) on Mobile Safari is the observed context.

Related

• Same useLinking/createMemoryHistory layer as the pushState SecurityError filed alongside this
  one in the same scan (APP-HTY / APP-HNR / APP-CFF), but a different call site and a different root
  cause — that one is a malformed path, this one is a loop.
• Found by a 7-day production crash scan of the latest 3 released versions (9.4.44, 9.4.45, 9.4.46)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082823064258927581
• Upwork Job ID: 2082823064258927581
• Last Price Increase: 2026-07-30

Issue Owner

Current Issue Owner: @gijoe0295

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @gijoe0295 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022082823064258927581

[MelvinBot]

Proposal

TL;DR: Two different redirectors disagree about where a validated private-domain user belongs, so they bounce that user back and forth on /onboarding/private-domain. Each bounce is one history.replaceState; Safari caps it at 100/10s and throws SecurityError. The rate limit is the symptom — the bug is the loop.

What is the root cause of that problem?

For a validated user on a private domain (isFromPublicDomain === false) who has accessible/joinable policies, two effects fight:

• The screen pushes them forward. BaseOnboardingPrivateDomain.tsx:107-127 redirects validated users off this screen via Navigation.navigate(..., {forceReplace: true}) → ONBOARDING_WORKSPACES (when joinablePoliciesLength > 0) or ONBOARDING_PURPOSE/EMPLOYEES. forceReplace maps to a react-navigation REPLACE → useLinking.onStateChange → history.replaceState (linkTo/index.ts:179-181). The effect has no idempotency guard, so it re-fires on any dependency change.

• The flow router pulls them back. The always-mounted useOnboardingFlowRouter calls getOnboardingInitialPath, which for a validated private-domain user hits OnboardingFlow.ts:147-152 — !isUserFromPublicDomain && hasAccessiblePolicies → returns the stale initialPath (still /onboarding/private-domain) → resetRoot back onto the screen.

The existing "don't stay on private-domain" guard at OnboardingFlow.ts:140 only covers public-domain validated users (isUserFromPublicDomain && isAccountValidated), so validated private-domain users fall through to line 147 and get sent back. Screen says "leave", router says "stay" → ping-pong → replaceState spam → Safari SecurityError.

Why it's intermittent / Safari-only, and the state that keeps it alive

• ONBOARDING_LAST_VISITED_PATH is written async via Onyx.merge after each navigation (NavigationRoot.tsx:90-94), so the router can read the previous path right after the screen already REPLACEd away — the classic re-entry window.
• On OnboardingWorkspaces, useFocusEffect calls getAccessiblePolicies(), flipping VALIDATE_USER_AND_GET_ACCESSIBLE_POLICIES.loading and mutating JOINABLE_POLICIES — the exact Onyx keys the private-domain effect depends on, so every bounce perturbs state and re-triggers both sides.
• Chromium coalesces rapid replaceState; Safari enforces 100/10s, which is why only Mobile Safari surfaces it (matches the Sentry platform data).

What changes do you think we should make in order to solve the problem?

Primary (removes the bounce source) — in getOnboardingInitialPath, make the router agree with the screen's own precondition: when the initialPath is /onboarding/private-domain and the account is validated, resolve forward (Workspaces if there are joinable policies, else Purpose/Employees) instead of returning the stale initialPath. Extend the existing guard at line 140 to also cover validated private-domain users rather than only public-domain ones. If the router and the screen never disagree, there's nothing to ping-pong.

Defensive (caps the blast radius) — in BaseOnboardingPrivateDomain.tsx:107-127, add a useRef "hasRedirected" guard so the redirect forceReplace fires at most once per mount, and only after getAccessiblePoliciesAction?.loading has definitively resolved (don't act on transient loading flips). This bounds replaceState calls even if a re-mount slips through.

What alternative solutions did you explore? (Optional)

Considered guarding only the screen effect, but that alone leaves the router still resetting back onto private-domain — the loop can persist. The router fix is the real one; the screen guard is belt-and-suspenders.

Confidence & how to confirm with logs

Medium. The two disagreeing redirectors and the missing idempotency guard are confirmed in code; the exact re-entry is a timing race on the async LAST_VISITED_PATH write, consistent with the Safari-only, intermittent symptom but not provable statically. To confirm: in APP-HT5 Mobile-Safari sessions, look for interleaved "Navigating to route" logs rapidly alternating between /onboarding/private-domain and /onboarding/workspaces (or /purpose) within a 10s window.

Open question: which target is the real counterpart in production — Workspaces (joinablePoliciesLength > 0) or Purpose (loading === false)? Logs would disambiguate and confirm whether the router fix should branch to Workspaces vs Purpose.

Related: Expensify/App#97470 (APP-HTY/HNR/CFF) is the sibling pushState SecurityError in the same useLinking/createMemoryHistory layer, but a different call site and root cause (a malformed path, not a loop) — fix them separately.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97473) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[gijoe0295]

@MelvinBot implement this

[MelvinBot]

🤖 Draft PR created: #97709

I implemented the approved proposal — both the primary router fix and the defensive screen guard:

• Primary — getOnboardingInitialPath now resolves forward when the last-visited path is /onboarding/private-domain and the account is validated (Workspaces if there are accessible policies, else Purpose/Employees), instead of returning the stale private-domain path. The existing guard covered only public-domain validated users; it now also covers validated private-domain users, so the router no longer sends them back onto the screen. Unvalidated users still stay put to confirm their code.
• Defensive — BaseOnboardingPrivateDomain now uses a useRef "hasRedirected" guard so the forced-replace redirect fires at most once per mount, bounding replaceState calls even if a re-mount slips through.

Testing: Added unit tests to tests/unit/OnboardingFlowTest.ts covering the new router branches (validated private-domain → join-workspaces / purpose / employees, and unvalidated private-domain staying on the screen). All 14 tests in that file pass, and typecheck, lint-changed, oxfmt, and the React Compiler compliance check are clean.

⚠️ I couldn't run a live browser smoke test of the onboarding flow — reaching /onboarding/private-domain in a validated-with-policies state requires SKIP_ONBOARDING=false, which is CI-owned and not toggleable in this environment. The router branch is fully covered by the added unit tests; the human co-author should still perform the manual/QA steps outlined in the PR before marking it ready for review.

Please mark it as "Ready for review" when it's ready.