[$250] Deeplink – Previous conversation opens for a moment when navigate via non-existing link

[izarutskaya]

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:**v1.4.61-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4480382
Email or phone of affected tester (no customers): ponikarchuks+68424@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Log in.
3. Open any chat
4. Navigate via non-existing link https://staging.new.expensify.com/anything
5. Go back using arrow
6. Navigate via non-existing link https://staging.new.expensify.com/anything
   again

Expected Result:

“Hmm... it's not here” page opens when navigate via non-existing link

Actual Result:

Previous conversation opens for a moment and then “Hmm... it's not here” page when navigate via non-existing link

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Screenshots/Videos

Bug6442856_1712612314454.Previous_conversation_opens_for_a_moment_when_navigate_via_non-existing_link.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01dc60681d78995448
• Upwork Job ID: 1777681979216637952
• Last Price Increase: 2024-04-23

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @kevinksullivan (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[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.

[izarutskaya]

@kevinksullivan I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

[mountiny]

This does not seem like a blocker to me, no detriment to user experience

Going to export this to see if some proposals can fix it though

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abdulrahuman5196 (External)

[ikevin127]

Proposal

Please re-state the problem that we are trying to solve in this issue

Previous conversation opens for a moment when navigating to a non-existing URL (not found page).

What is the root cause of that problem?

The root cause comes from this logic within the ReportScreenIDSetter component.

What's happening exactly ?

The above-referenced useEffect logic sets the reportID of the last accessed report in the route params, before navigation to a non-existing page is initiated resulting in the not found page.

How does this happen ?

1. The first if of the useEffect checks if route?.params?.reportID exists -> when navigating to a non-existing page, route?.params?.reportID will be undefined.
2. The first if is skipped-> the second if comes into play and sets the reportID of the last accessed report in the route params -> this is why we're navigated to the last accessed report before we're shown the not found page.

What changes do you think we should make in order to solve the problem?

We have to delay the setting the last accessed reportID in the route params. To do this we can wrap the final if of the useEffect with InteractionManager.runAfterInteractions which adds just the right amount of delay, but still sets the last accessed reportID in the route params (this is crucial for maintaining the current logic).

Code changes:

    InteractionManager.runAfterInteractions(() => {
        if (!reportID) {
            return;
        }
        navigation.setParams({reportID: String(reportID)});
    });

By doing this we're basically delaying setting the last accessed reportID in the route params, which won't navigate to the report first -> allowing the not found page to be displayed. Upon closing (or going back) the not found page, the user will be navigated to the last accessed report since the call to set the last accessed reportID in the params was made (with delay).

This means we will see the loading skeleton in the central pane then the not found page, instead of seeing / opening the report and only after that seeing the not found page.

Videos (before / after)

MacOS: Chrome / Safari

Before	After
before.mov	after.mov

[mountiny]

Thanks! That looks good to me but curious for a review from @abdulrahuman5196 too. Thanks!

[ikevin127]

abdulrahuman5196 from (Slack):

Hi Team, I will be working on lesser capacity for next 2 weeks. I will un-assign myself from issues if I am unable to handle. Also feel free to re-assign if you see any issue delayed because of me.

cc @mountiny

[abdulrahuman5196]

Hi, I will work on this issue in my morning

[abdulrahuman5196]

Checking now.

[abdulrahuman5196]

I am not seeing this issue in staging. Let me know if i need to do anything else to repro.

Screen.Recording.2024-04-12.at.9.14.14.PM.mov

[ikevin127]

Looks like the issue is gone, not reproducible anymore.
We can ask for a double-check from the testing team and close if confirmed.

[mountiny]

waiting for a retest

[melvin-bot]

@kevinksullivan, @mountiny, @abdulrahuman5196 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@kevinksullivan @mountiny @abdulrahuman5196 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!

[mountiny]

Waiitng for retest

[kevinksullivan]

Unable to reproduce, so I'm closing out!