fix(onboarding): suppress welcome dialog while 2FA setup is pending#59259
Closed
posthog[bot] wants to merge 1 commit into
Closed
fix(onboarding): suppress welcome dialog while 2FA setup is pending#59259posthog[bot] wants to merge 1 commit into
posthog[bot] wants to merge 1 commit into
Conversation
Invited users in orgs with enforce_2fa=true would hit a deterministic 403 on the welcome endpoint before completing 2FA setup, surfacing a misleading "Try again" banner that competed with the 2FA setup modal. Gate the auto-open on a best-effort 2FA-status check, and treat a 403/two_factor_setup_required response as a "suppress dialog" signal rather than a generic error. Retry the load when 2FA setup completes. Generated-By: PostHog Code Task-Id: b3c67bb3-9f83-4b9c-9eeb-d6e71e8c1e30
Contributor
|
🎭 Playwright didn't run on this PR — your changes touch code that could affect E2E behavior, but Playwright is opt-in via label now to keep CI cost down. Add the Most PRs don't need this. Real regressions still get caught on master and fix-forward. |
Contributor
|
Size Change: -7.34 kB (-0.01%) Total Size: 118 MB 📦 View Changed
ℹ️ View Unchanged
|
Contributor
Author
|
CI status note from the agent run:
Per agent hard limits, I won't make edits outside this PR's scope to clear the master-broken lint. Re-running CI after master is fixed should turn this PR green. |
Contributor
|
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, please remove the |
Contributor
|
This PR was closed due to lack of activity. Feel free to reopen if it's still relevant. |
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.
Problem
Invitees in organizations with
enforce_2fa=trueconsistently see a broken welcome dialog on first login.MaybeWelcomeDialogauto-opens on/project/<id>/homeand callsGET /api/organizations/@current/welcome/current/. That endpoint is not in the 2FA whitelist (posthog/helpers/two_factor_session.py), so it 403s withcode: "two_factor_setup_required"for any user who hasn't yet set up TOTP / a passkey. The dialog renders the generic "We couldn't load your team's activity" banner with a "Try again" button that re-fires the same 403 — at the same time the globalapiStatusLogicis opening the 2FA setup modal in the background.Telemetry from the report: ~427
welcome_screen_load_failedevents vs ~18,908welcome_screen_shownover 14 days (~2.2%), with replays through 2026-05-20 confirming it's still recurring.Changes
Frontend-only fix in
welcomeDialogLogic:twoFactorSetupRequiredreducer set when the loader sees a 403 withcode === "two_factor_setup_required". The error is no longer treated as a generic "load failed" — nowelcomeDataErrorflag, nowelcome_screen_load_failedevent, and the dialog is suppressed.isPendingTwoFactorSetupselector — best-effort pre-emptive check usinguser.organization.enforce_2fa,user.is_2fa_enabled,user.passkeys_enabled_for_2fa. When this is true, the auto-fetch never fires, so we don't pay for the request at all. The selector intentionally errs on the side of "don't suppress" (the response-code path is the authoritative fallback) since we can't perfectly replicate the backend check (SSO bypass, session-enforcement date, has-passkeys ledger) on the client.shouldShowDialog, so the modal stays closed while 2FA is pending.isPendingTwoFactorSetuptransitioningtrue → false: onceuserLogicrefetches after the user completes 2FA setup, retry the load (the existingshouldShowDialog → loadWelcomeDatasubscription is a no-op oncehasLoadedOnceflips true).No backend change — the user-visible bug is purely the racing UI. Adding the path to
WHITELISTED_PREFIXESwould also work but felt like the wrong trade-off (weakening the 2FA gate to fix a UI race).How did you test this code?
I'm an agent. I did not run manual browser testing. Automated coverage I added/ran:
pnpm jest -- src/scenes/welcome/welcomeDialogLogic.test.ts— 9 tests pass, including three new ones:enforce_2fais on and 2FA isn't set up (no request fired)loadUserSuccess)code: "two_factor_setup_required"(no error banner)Publish to changelog?
no
🤖 Agent context
welcome_screen_load_failedpattern with replays showing invitees dismissing the broken dialog before completing mandatory 2FA setup./api/organizations/<id>/welcome/current/toWHITELISTED_PREFIXESas a complementary backend fix. Rejected because (a) the welcome endpoint exposes org-scoped aggregate data we'd rather keep behind the 2FA gate, and (b) the frontend fix removes the symptom entirely without weakening the gate.isPendingTwoFactorSetuptrue → falsesubscription so the dialog appears naturally once the user finishes the 2FA modal in the same tab; without it the stickyhasLoadedOnceflag would block the retry.Created with PostHog Code