fix: navigate to Concierge chat after login from Concierge deep link on web - #96387
fix: navigate to Concierge chat after login from Concierge deep link on web#96387x-dev90 wants to merge 31 commits into
Conversation
Codecov Report❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f870138760
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
Hi @brunovjk, I tested one additional edge case and would like to confirm the expected behavior. Steps:
I also tested this on My understanding is that the app currently preserves the original Could you please confirm how we should handle this? Should this PR keep the current Tested on main: Screencast.From.2026-07-18.22-40-19.mp4 |
|
Hi @brunovjk, just following up on this PR. I addressed the AI feedback by persisting the pending Concierge deep-link intent in Could you please review the latest changes when you have a chance? |
|
@x-dev90 It’s not very consistent, so I couldn't record a video, but it happens sometimes. If you access the deeplink with Also, If you enter using only the Screen.Recording.2026-07-20.at.14.33.42.mov |
Hi @brunovjk ,I updated the implementation to preserve the pending I added focused unit coverage for the Concierge redirect, explicit root cancellation, direct root signup, and reload cases. I also adjusted the reload detection to avoid direct deprecated API access. Could you please review again when you have a chance? Thank you! After Fix: Screencast.From.2026-07-22.01-34-13.mp4Screencast.From.2026-07-22.01-31-38.mp4Screencast.From.2026-07-22.01-36-26.mp4Screencast.From.2026-07-22.01-37-43.mp4 |
|
Thanks for the effort @x-dev90, but now it seems to be failing on the initial issue: Screen.Recording.2026-07-22.at.13.38.18.mov |
|
Hi @brunovjk, could you please review this PR again when you have a chance? After the previous approval, I found and addressed a few remaining edge cases. The earlier fix covered refreshing before signup after opening the deep link, but the latest updates also cover refreshes during and after signup while onboarding is still in progress. The PR now preserves the original I also addressed the two-tab sync case: if I added focused unit coverage for these cases as well. Could you please take another look? Before Screencast.From.2026-07-25.15-57-36.mp4Screencast.From.2026-07-25.16-04-16.mp4vokoscreenNG-2026-07-25_01-00-50.mp4After Fix: Screencast.From.2026-07-25.16-18-52.mp4Screencast.From.2026-07-25.15-12-55.mp4Screencast.From.2026-07-25.16-20-49.mp4 |
Hi @cristipaval, thanks for waiting. I’ve finished the additional testing and addressed the remaining edge cases, including refresh during onboarding, Submit workspace onboarding, and two-tab intent sync. This should be ready for you once @brunovjk re-reviews the latest changes. |
|
@brunovjk Gentle bump when you have a chance. Thanks! |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a5eb8b0f94
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } else if (normalizedRoute === '/') { | ||
| // Root is an explicit normal signup intent, so it cancels Concierge unless it is a reload replay. | ||
| setPendingHomeDeepLinkForRoot(); |
There was a problem hiding this comment.
Only store Home when replacing a pending Concierge intent
For an ordinary logged-out web load at /, openReportFromDeepLink() reaches this branch even when no Concierge intent exists, so it creates a pending Home flag. When onboarding finishes, navigateToPendingDeepLinkAfterOnboarding() consumes that flag and returns before the normal RHP variant, admin-room, or workspace navigation runs. Consequently, normal signups from the root URL are forced to Home instead of following their existing onboarding destination; the Home marker should only be created when it is actually canceling a pending Concierge intent.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Hi @brunovjk, thank you for taking the time to review this.
I tested the fresh / signup flow on main, without opening /concierge first. On main, opening /, signing up, and completing onboarding navigates to Concierge. I also added an extra fix in this PR so / -> signup/onboarding now lands on Home instead of Concierge.
This PR now fixes both related flows:
/concierge-> signup/onboarding preserves the Concierge intent./-> signup/onboarding lands on Home instead of Concierge.
I also re-tested the other onboarding flows, and they continue to behave as expected.
Could you please confirm if this is the behavior we want to keep?
| // Submit workspace onboarding bypasses navigateAfterOnboarding(), so honor the same pending deep-link intent here. | ||
| if (navigateToPendingDeepLinkAfterOnboarding(conciergeReportID)) { | ||
| return; |
There was a problem hiding this comment.
Avoid consuming onboarding intents from the Submit welcome modal
When an existing user signs in through /concierge, the normal deep-link handler opens Concierge but never consumes the new pending flag because no onboarding completion occurs. If that user then confirms the proactively shown SubmitPlanWelcomeModal, its shouldCompleteOnboarding=false path still reaches this check, consumes the stale flag, and returns before navigating to Workspace Categories or opening the side panel. Restrict this pending-intent handling to actual onboarding callers, or clear the intent after it has been fulfilled for an already-onboarded sign-in.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@brunovjk, thanks for checking this.
I tested the existing-user sign-in flow separately, but I could not reproduce the issue. Signing in through /concierge opens Concierge as expected, and confirming the SubmitPlanWelcomeModal still navigates to Workspace Categories with the side panel open.
Since the sign-in flow works separately from the signup/onboarding flow covered by this PR, I’m not seeing the stale pending intent issue described here. Could you please confirm if there are specific steps I should test?
|
@brunovjk, could you please check this when you get a chance. thanks. |
|
Great work, @x-dev90. However, the Home screen opens first, briefly, and then the concierge page opens a moment later. Screen.Recording.2026-07-28.at.11.12.54.movDo you think we can fix this? Thanks. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e2adfa85d5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
Hi @brunovjk, thank you for taking the time to review this! I've added one final fix for the Test steps:
Since this is closely related to the same post-onboarding routing behavior, I think it makes sense to keep it in this PR. Could you please take another look and let me know if this approach looks good? |
Explanation of Change
Preserve the
/conciergedeep-link intent when a logged-out user signs up with a new account, then consume that intent after onboarding before falling back to Home.This keeps the existing pre-onboarding deep-link guard intact, avoids reopening stale non-Concierge deep links, and routes the user to the Concierge report when available. If the Concierge report ID is not ready yet, it navigates to
ROUTES.CONCIERGEsoConciergePagecan resolve the chat.Fixed Issues
$ #95365
PROPOSAL: #95365 (comment)
Tests
Case 1: Original Flow
/conciergedirectly in the browserAdditional Cases
/conciergedirectly in the browser////concierge//concierge?test=1/concierge#testOffline tests
Same as tests.
QA Steps
Same as tests.
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
Screen_Recording_20260717_182305_Chrome.mp4
iOS: Native
iOS: mWeb Safari
Screen.Recording.2026-07-17.at.6.33.33.PM.mp4
MacOS: Chrome / Safari
Screen.Recording.2026-07-17.at.5.56.41.PM.mp4