fix(onboarding): ensures proper returnTo after email validation#2806
Merged
ygrishajev merged 1 commit intomainfrom Feb 23, 2026
Merged
fix(onboarding): ensures proper returnTo after email validation#2806ygrishajev merged 1 commit intomainfrom
ygrishajev merged 1 commit intomainfrom
Conversation
Contributor
📝 WalkthroughWalkthroughExtracted a VerifyEmailPage component with dependency injection and tests; refactored OnboardingRedirectEffect to accept injected dependencies and export EXCLUDED_PREFIXES (extended with "/user/verify-email"); page layer now re-exports the new VerifyEmailPage; tests added for both components. Changes
Sequence Diagram(s)sequenceDiagram
participant Browser
participant VerifyEmailPage as VerifyEmailPage (component)
participant SearchParams as useSearchParams
participant VerifyHook as useVerifyEmail
participant Router
participant UrlService
Browser->>VerifyEmailPage: request /user/verify-email?email=...
VerifyEmailPage->>SearchParams: read email
alt email present
VerifyEmailPage->>VerifyHook: mutate({ email })
VerifyHook-->>VerifyEmailPage: onSuccess / onError
alt onSuccess
VerifyEmailPage->>UrlService: build onboarding URL (returnTo=/)
VerifyEmailPage->>Router: push(onboardingUrl)
else onError
VerifyEmailPage-->>Browser: render error UI
end
else email missing
VerifyEmailPage-->>Browser: render error UI
end
sequenceDiagram
participant App
participant OnboardingEffect as OnboardingRedirectEffect
participant UserHook as useUser
participant WalletHook as useWallet
participant Router
App->>OnboardingEffect: mount
OnboardingEffect->>UserHook: get userId, loading
OnboardingEffect->>WalletHook: get wallet, connected, loading
alt userId && !wallet && !connected && not excludedPath
OnboardingEffect->>Router: push("/signup?returnTo=encodedPath")
else
OnboardingEffect-->>App: no redirect
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2806 +/- ##
==========================================
- Coverage 53.73% 52.98% -0.75%
==========================================
Files 1018 983 -35
Lines 23586 22756 -830
Branches 5757 5664 -93
==========================================
- Hits 12673 12057 -616
+ Misses 9510 9308 -202
+ Partials 1403 1391 -12
*This pull request uses carry forward flags. Click here to find out more.
🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@apps/deploy-web/src/components/onboarding/OnboardingRedirectEffect/OnboardingRedirectEffect.spec.tsx`:
- Line 9: Replace the hardcoded root suite string with the component's runtime
name: change the describe call from "OnboardingRedirectEffect" to
OnboardingRedirectEffect.name in the OnboardingRedirectEffect.spec.tsx test;
ensure the OnboardingRedirectEffect symbol used in the describe is imported or
otherwise available in the test so the .name property resolves at runtime.
In
`@apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.spec.tsx`:
- Line 9: Change the root test suite to use the component's .name instead of a
hardcoded string: replace the top-level describe("VerifyEmailPage", ...) with
describe(VerifyEmailPage.name, ...) (ensure the VerifyEmailPage symbol
imported/available in the spec file) so automated refactors can locate the suite
by symbol.
- Around line 22-47: Replace assertions that use screen.getByText and
screen.getByTestId with the non-throwing query variants so tests don't error on
absent nodes: update the expectations in VerifyEmailPage.spec.tsx to use
screen.queryByText for the loading, error and "isVerified is null" cases and use
screen.queryByTestId for the CheckCircleIcon assertion; locate the assertions
around the setup helper and the capturedOnSuccess / capturedOnError interactions
and change getBy* -> queryBy* while keeping the same text and test id values.
In
`@apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.tsx`:
- Around line 6-75: The code calls d.useSearchParams().get("email") without
guarding against useSearchParams returning null; update VerifyEmailPage to
handle null by using optional chaining or a null check when obtaining email
(e.g., derive email from d.useSearchParams()?.get("email") or check the result
before calling .get), and ensure subsequent logic (the d.useWhen(email, ...),
state initialization, and verifyEmail usage) gracefully handles email being
null/undefined; locate the reference in VerifyEmailPage where email is assigned
and adjust that line and any dependent usage to be null-safe.
...loy-web/src/components/onboarding/OnboardingRedirectEffect/OnboardingRedirectEffect.spec.tsx
Outdated
Show resolved
Hide resolved
apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.spec.tsx
Outdated
Show resolved
Hide resolved
apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.spec.tsx
Outdated
Show resolved
Hide resolved
apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.tsx
Show resolved
Hide resolved
ygrishajev
force-pushed
the
feature/auth
branch
from
e0eaacf to
9273463
Compare
Contributor
There was a problem hiding this comment.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In
`@apps/deploy-web/src/components/onboarding/VerifyEmailPage/VerifyEmailPage.tsx`:
- Around line 70-71: VerifyEmailPage currently calls
d.useSearchParams().get("email") directly which can throw if useSearchParams()
returns null during pre-render; update the code in VerifyEmailPage to first
capture the result of d.useSearchParams(), check for null/undefined, and only
call .get("email") when it's non-null (use a safe fallback like undefined or
empty string for email otherwise) so d.useSearchParams() is null-safe.
stalniy
approved these changes
Feb 22, 2026
apps/deploy-web/src/components/onboarding/OnboardingRedirectEffect/OnboardingRedirectEffect.tsx
Show resolved
Hide resolved
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
2 participants
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.
Why
Users were stuck in a redirect loop after email verification.
OnboardingRedirectEffectredirected users from/user/verify-emailto onboarding withreturnToset to/user/verify-email?email=.... After completing onboarding, users were sent back to verify-email, which triggered the onboarding redirect again — creating an infinite loop. The root cause was that/user/verify-emailwas not in the excluded paths list for the onboarding redirect.What
/user/verify-emailtoEXCLUDED_PREFIXESinOnboardingRedirectEffectso the verify-email page is not intercepted by the onboarding redirect{ returnTo: "/" }to theUrlService.onboarding()call in the verify-email page so users navigate to/after completing onboardingVerifyEmailPagefrom the Next.js page file into its own component undercomponents/onboarding/VerifyEmailPage/OnboardingRedirectEffectandVerifyEmailPagefor testabilityOnboardingRedirectEffect(11 tests) andVerifyEmailPage(6 tests)Summary by CodeRabbit
New Features
Tests