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 51 commits into
Conversation
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
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, I’ve cleaned up the PR so the implementation is now focused on the original proposal. It preserves the pending Could you please take another look when you have a chance? thanks. |
|
@brunovjk, just a gentle bump. Thanks! |
|
Hi @x-dev90, quick question: I noticed the Url.hasSecureLinkKey(...) block in openReportFromDeepLink was removed. Was that intentional? That logic handled secure-link joins and may be a regression if dropped. Thank you. |
Hi @brunovjk, thanks for the review. I restored the unrelated changes and kept the PR scoped to the I also restored the unrelated secure-link handling, existing onboarding navigation behavior, and test mocks. Could you please review again when you have a chance? |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari
96387_web_chrome_workspace.mov
96387_web_chrome_refresh_onboarding.mov
96387_web_chrome_.concierge.mov
96387_web_chrome_.concierge.test.1.mov |
|
@cristipaval could you please help confirm the expected behavior here? I retested the latest PR and found:
The PR looks good to me otherwise, but I’m unsure about the last case. Should the original |
@flaviadefaria could you please confirm from the product perspective? |
Hi @flaviadefaria, could you please verify this from the product perspective? Thanks! |
|
@flaviadefaria, gentle bump on this comment. Thanks! |
|
Sorry I was OoO last week and am only catching up now. I might be missing something, but I’d expect any new sign-up to be routed through the onboarding flow, regardless of the link they used. If it’s a brand-new account, I’d assume they only ended up with the Concierge link by mistake, so onboarding should take precedence. For an existing account, though, I agree that the user should land directly in the Concierge chat. @trjExpensify cc'ing you here for a buddy check, as I might be missing something. |
|
Yeah, I assume we created this I don't really see the utility of the deep link for a brand new user, so I'd be open to just dropping it for brand new accounts and proceeding through onboarding as normal in all cases. |
@brunovjk, what’s the next step here? Thanks! |
|
I think this deeplink existed so we can add this kink to olddot and support pages and its generic and makes sense to the reader |
|
@brunovjk, just a gentle bump. Thanks! |
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#test.Offline 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