[$250] [Search v2.2] Redirected back to "Expenses" when refreshing the page while in "chats"

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.0.31-0
Reproducible in staging?: Y
Reproducible in production?: N/A
Email or phone of affected tester (no customers): applausetester+shsb22ertt@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

1. Log into newdot with any account
2. Go to Search option from bottom tab
3. Click on "Chat" type from LHP
4. Click on any message from the rendered results
5. When the report view is opened in RHP refresh the browser

Expected Result:

App stays in "Chat" search type

Actual Result:

App navigates to "Expense" search type in the background while the RHP of the report view is still opened

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6597783_1725902417521.2024-09-09_19_16_26.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021833265839061428544
• Upwork Job ID: 1833265839061428544
• Last Price Increase: 2024-09-09

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @Kicu

[melvin-bot]

Triggered auto assignment to @NikkiWines (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

Triggered auto assignment to @johncschuster (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[IuliiaHerets]

We think that this bug might be related to #wave-control

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[luacmartins]

I can take this since it's part of Search

[luacmartins]

cc @shubham1206agra

[melvin-bot]

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

[melvin-bot]

Current assignee @ikevin127 is eligible for the External assigner, not assigning anyone new.

[luacmartins]

This also happens with the current data types, e.g. Invoice, Trips. We don't currently store the context of the Search query when viewing the item in the RHP. Demoting to NAB. @Kicu @WojtekBoman

[Kicu]

Yup it is quite clear why this behaviour happens, based on how search + navigation works.

I think we'd need to think a bit how best to improve this behaviour if we want to.

In general we are basing the whole state of search on current q parameter in URL. This has been great so far - single source of truth and we have 0 bugs related to synchronisation between query and other parts of search.

But this also means behaviours like this one, where if we don't have query in URL then we loose the previous state. I'm a bit reluctant to change this behaviour for now. 🤔

[luacmartins]

I agree, but I think that's something we'll eventually have to do to allow for a better navigation experience. We don't need to rush though and can think more carefully on how to solve this without creating bugs.

[johncschuster]

Thanks for the thoughtful discussion @Kicu and @luacmartins! What's the next step here? Do we need to take this to Slack to discuss in more detail?

[luacmartins]

@Kicu let me know if you or someone at SWM can take on this issue.

[Kicu]

@luacmartins but what is the expectation. I described that this is kinda complex and we should think about how to best solve it. Then you agreed.
And now what do we want to do? should I just come up with a solution that will allow us to always go back?

[luacmartins]

Oh I just meant to take this on and investigate a good holistic solution for this. Let's not rush this one

[Kicu]

Alright makes sense.
Please assign me to the issue then :)

[melvin-bot]

❌ There was an error making the offer to @ikevin127 for the Reviewer role. The BZ member will need to manually hire the contributor.

[melvin-bot]

@Kicu, @johncschuster, @luacmartins, @ikevin127 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[ikevin127]

Not overdue, this is being worked on.

[Kicu]

I will have some update on this issue today or tomorrow, I was handling some other search tasks last week

[Kicu]

@luacmartins
So I consulted with both @adamgrzybowski and @WojtekBoman and our general consensus is that we will use backTo param to handle this case.

Correctly set and handled backTo will take care of both: having proper screen underneath the modal and going back to correct screen on back button click.

I should have the PR ready tomorrow, it will be relatively small so I can do it in between other 2.4 tasks

[melvin-bot]

@Kicu @johncschuster @luacmartins @ikevin127 this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[Kicu]

calm down melvin ☮️ this will have a PR opened today

[Kicu]

PR is open for review