[HOLD for payment 2024-12-17] [HOLD for payment 2024-12-16] [$250] Expense - Not here page shows up briefly when deleting the expense

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.8-1
Reproducible in staging?: Y
Reproducible in production?: N
Found when executing PR : #44537
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to DM.
3. Submit two expenses to the user.
4. Open any of the transaction thread.
5. Tap on the report header.
6. Tap Delete expense..
7. Delete the expense.

Expected Result:

Not here page will not show up when deleting the expense.

Actual Result:

Not here page shows up briefly when deleting the expense.

Workaround:

Unknown

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

Bug6544678_1721193497553.ScreenRecording_07-17-2024_13-15-33_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c66dfe570a289fac
• Upwork Job ID: 1813534350182069816
• Last Price Increase: 2024-08-20
• Automatic offers:
• alitoshmatov | Reviewer | 103693223
• wildan-m | Contributor | 104145017

Issue Owner

Current Issue Owner: @sonialiap

[melvin-bot]

Triggered auto assignment to @sonialiap (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.

[melvin-bot]

Triggered auto assignment to @iwiznia (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ 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]

We think this issue might be related to the #collect project.

[izarutskaya]

Production

Screen_Recording_20240717_113000_Chrome.mp4

[melvin-bot]

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

[melvin-bot]

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

[allgandalf]

We pass isFromRHP to true without checking the screen size (whether we are on larger screen or smaller):

App/src/pages/ReportDetailsPage.tsx

Line 778 in fc9b7ac

ReportUtils.navigateBackAfterDeleteTransaction(navigateBackToAfterDelete.current, true);

This will trigger us to dismiss the modal first and then navigate back:

App/src/libs/ReportUtils.ts

Lines 3594 to 3600 in fc9b7ac

	if (isFromRHP) {
	Navigation.dismissModal();
	}
	Navigation.isNavigationReady().then(() => {
	Navigation.goBack(backRoute);
	});
	}

Simplest fix would be to use the check the screen size from the hook useResponsiveLayout and only pass true if we are on bigger screen

const {isSmallScreenWidth} = useResponsiveLayout();

ReportUtils.navigateBackAfterDeleteTransaction(navigateBackToAfterDelete.current, !isSmallScreenWidth ? true: false); 

I assume there is a check for large screen too, both can be used either ways

[allgandalf]

I assume that is what was intended with the PR #44537

[allgandalf]

does that make sense to you @iwiznia ?

[iwiznia]

Oh right, seems that PR did not fix the issue it was intended to fix, going to close in favor of that issue

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[daledah]

Edited by proposal-police: This proposal was edited at 2024-08-06 13:59:34 UTC.

Proposal

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

Not here page shows up briefly when deleting the expense.

What is the root cause of that problem?

After deleting the transaction, we delete the data first here, then navigate later

App/src/pages/ReportDetailsPage.tsx

Line 778 in 3710936

ReportUtils.navigateBackAfterDeleteTransaction(navigateBackToAfterDelete.current, true);

So the data will be updated even before the user finishes the navigation back, this causes the brief deleted-transaction data (not found page/[Deleted expense] text) to show in the screen (which is still navigating back).

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

We should navigate the user back first, then delete the transaction data in the background after the user has successfully navigated. This will make sure through out the navigation back, the user still sees the correct transaction data.

• Update this to

const { urlToNavigateBack } = IOU.prepareToCleanUpMoneyRequest(iouTransactionID, requestParentReportAction, true);
navigateBackToAfterDelete.current = urlToNavigateBack;

So at this step we just set the navigateBackToAfterDelete.current and not deleting the data yet (we'll delete in a step later). This logic is the same as the values returned when calling IOU.deleteMoneyRequest here so there'll be no problem

• In

  App/src/pages/ReportDetailsPage.tsx

  Line 806 in bdeab94

  ReportUtils.navigateBackAfterDeleteTransaction(navigateBackToAfterDelete.current, true);

  (after triggering navigation back), wait for the navigate back to complete (using the animated transition as we did at useAutoFocusInput) and only delete the transaction data then (this part)

ReportUtils.navigateBackAfterDeleteTransaction(navigateBackToAfterDelete.current, true);

setTimeout(() => {
    IOU.deleteMoneyRequest(iouTransactionID, requestParentReportAction, isSingleTransactionView);
}, CONST.ANIMATED_TRANSITION);

In summary, we only change the order in which optimistic data update and navigation back happens, we don't make any logic change. That's for submit expense case, we should check track expense case and handle in similar manner.

What alternative solutions did you explore? (Optional)

We could additionally add the change suggested above here, but this does not fully fix the issue, [Deleted expense] still shows and also buttons disappearing, before the user is navigated back. So it's an incremental thing we can add.

Alternative to waitForNavigate approach, we can use setTimeout with the navigation timeout (similar to in here). Or we can delete the data in InteractionManager.runAfterInteractions, but it might not work as reliably.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.72-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix: Expense - Not here page shows up briefly when deleting the expense #52740

If no regressions arise, payment will be issued on 2024-12-16. 🎊

For reference, here are some details about the assignees on this issue:

• @wildan-m requires payment automatic offer (Contributor)
• @alitoshmatov requires payment automatic offer (Reviewer)
• @daledah requires payment (Needs manual offer from BZ)

[melvin-bot]

@alitoshmatov @sonialiap @alitoshmatov The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.73-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• patch success data to prevent issue report object not considered to null #53616

If no regressions arise, payment will be issued on 2024-12-17. 🎊

For reference, here are some details about the assignees on this issue:

• @wildan-m requires payment automatic offer (Contributor)
• @alitoshmatov requires payment automatic offer (Reviewer)
• @daledah requires payment (Needs manual offer from BZ)

[melvin-bot]

@alitoshmatov @sonialiap @alitoshmatov The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

Triggered auto assignment to @RachCHopkins (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.

[sonialiap]

I'm OOO Dec 16-20, adding a leave buddy

next steps:

• @alitoshmatov to complete checklist
• BZ to make payment

[alitoshmatov]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: https://github.com/Expensify/App/pull/43251/files#r1887128320

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion: No discussion started

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

1. Open the App.
2. Go to any DM
3. Submit two expenses to the user.
4. Open any transaction thread.
5. Tap on the report header.
6. Select Delete Expense and confirm deletion.
7. Verify that the "Not here" page does not appear after deleting the expense. This could happen briefly, and usually in mobile devices

Do we agree 👍 or 👎