[HOLD for payment 2024-11-20] [$250] Expense-Expense preview is hidden briefly when returning to expense report via header subtitle

[lanitochka17]

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.40-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: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to DM
3. Submit at least two expenses to the user
4. Go to transaction thread of the first expense
5. Click on the header subtitle link to go back to expense report

Expected Result:

The second expense preview will show instantly after returning to expense report via header subtitle (production behavior)

Actual Result:

The second expense preview is hidden briefly after returning to expense report via header subtitle

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

Add any screenshot/video evidence

Bug6615158_1727291074734.IOU_thread.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021839062492993280361
• Upwork Job ID: 1839062492993280361
• Last Price Increase: 2024-10-30
• Automatic offers:
• huult | Contributor | 104757569

Issue Owner

Current Issue Owner: @RachCHopkins

[melvin-bot]

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

[lanitochka17]

We think that this bug might be related to #wave-collect - Release 1

[francoisl]

I also notice a short delay on production, albeit shorter than on staging. Roughly like 50ms on production, and 200ms on staging.
It doesn't look like there's any API call happening when returning to the parent report, so it's probably not due to anything changing in Onyx.

There's nothing that stands out in the checklist so I'm going to open this up for proposals. Doesn't seem worthy of blocking though.

[melvin-bot]

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

[melvin-bot]

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

[mkzie2]

Proposal

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

The second expense preview is hidden briefly after returning to expense report via header subtitle

What is the root cause of that problem?

1. The expense preview is hidden briefly

loadNewerChats is called with a delay here because we wrapped it in InteractionManager.runAfterInteractions and requestAnimationFrame

App/src/pages/home/report/ReportActionsList.tsx

Lines 617 to 619 in 2d0d4e9

	const onStartReached = useCallback(() => {
	InteractionManager.runAfterInteractions(() => requestAnimationFrame(() => loadNewerChats(false)));
	}, [loadNewerChats]);

That leads isFirstLinkedActionRender ref being updated to false after more delay here

App/src/pages/home/report/ReportActionsView.tsx

Line 395 in 2d0d4e9

handleReportActionPagination({firstReportActionID: newestReportAction?.reportActionID});

As a result, it takes more time to change reportActions from [preview1] (isFirstLinkedActionRender.current is true) to [preview1, preview 2] (isFirstLinkedActionRender is changed to false)

App/src/pages/home/report/ReportActionsView.tsx

Lines 232 to 234 in 2d0d4e9

	if (isFirstLinkedActionRender.current) {
	return combinedReportActions.slice(indexOfLinkedAction);
	}

2. This happens every time we click on the header subtitle of the transaction thread report

We use goBack with shouldEnforceFallback as true to ensure we navigate to the previous report instead of going back. Then because it's a new screen in the stack, this bug happens as the reason at the point 1.

App/src/components/ParentNavigationSubtitle.tsx

Line 47 in 2d0d4e9

Navigation.goBack(ROUTES.REPORT_WITH_ID.getRoute(parentReportID, parentReportActionID), true);

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

1. If we agree that it's not a bug we can do nothing here since this change is added here to fix another bug. If not, we should remove this change and find another solution to fix the issue related to this change.

App/src/pages/home/report/ReportActionsList.tsx

Lines 617 to 619 in 2d0d4e9

	const onStartReached = useCallback(() => {
	InteractionManager.runAfterInteractions(() => requestAnimationFrame(() => loadNewerChats(false)));
	}, [loadNewerChats]);

2. To prevent the flicker when clicking on the header subtitle, we should use Navigation.isNavigationReady here instead of passing shouldEnforceFallback param as true

Navigation.isNavigationReady().then(() => {
    Navigation.goBack(ROUTES.REPORT_WITH_ID.getRoute(parentReportID, parentReportActionID));
});

App/src/components/ParentNavigationSubtitle.tsx

Line 47 in 2d0d4e9

Navigation.goBack(ROUTES.REPORT_WITH_ID.getRoute(parentReportID, parentReportActionID), true);

What alternative solutions did you explore? (Optional)

[melvin-bot]

@francoisl, @fedirjh Eep! 4 days overdue now. Issues have feelings too...

[francoisl]

@fedirjh are you available to review the proposal above please?

[fedirjh]

Yep, on it.

[melvin-bot]

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

[fedirjh]

@mkzie2 Thanks for the proposal. I agree with your analysis . However, the second option in your solution won't work if we deep link to the transaction report first and then navigate back to the expense report.

I also notice a short delay on production, albeit shorter than on staging. Roughly like 50ms on production, and 200ms on staging.

@francoisl This is a regression from #49477 as @mkzie2 mentioned . Should we just leave things as they are and close this issue since the behavior exists in production, or should we revert the changes introduced in #49477 and look for another solution (cc @ikevin127 @huult)? Alternatively, should we keep this open to explore other options?

[mkzie2]

However, the second option in your solution won't work if we deep link to the transaction report first and then navigate back to the expense report.

@fedirjh This case will not work because in this case it's the first time the expense report is rendered and as I mentioned in the RCA, this bug will happen.

App/src/pages/home/report/ReportActionsList.tsx

Lines 617 to 619 in 2d0d4e9

	const onStartReached = useCallback(() => {
	InteractionManager.runAfterInteractions(() => requestAnimationFrame(() => loadNewerChats(false)));
	}, [loadNewerChats]);

[ikevin127]

@fedirjh Thanks for the ping!

Should we just leave things as they are and close this issue since the behavior exists in production

I'd vote for close since there was always a small delay in this case. However:

The delay caused by InteractionManager.runAfterInteractions combined with requestAnimationFrame can vary depending on the device's performance and current load. However, in general:

• InteractionManager.runAfterInteractions queues work to run after all ongoing interactions (like gestures or animations) are completed. The exact timing depends on when the ongoing interactions finish, which can vary but typically happens immediately after the current interaction finishes.

• requestAnimationFrame schedules the callback to be executed on the next repaint, which is typically around 16.67 milliseconds on a 60Hz display (since the screen refreshes every 16.67ms).

So the total delay would be roughly the time it takes for the current interactions to complete plus one frame delay (around 16.67ms). In most cases, the combined delay will be in the range of 16.67ms to a few hundred milliseconds, depending on how long the interactions take to finish.

Given this, if it's really important to have 0 delay and the expense preview show instantly, I agree that the logic should be adjusted and our PR considered a regression 👍

[huult]

@ikevin127 May I ask if a final decision has been made on that case?

[ikevin127]

♻️ We're awaiting on a decision from the people assigned to this issue.

[huult]

Thank you all. I will create a pull request after the issue I asked about in the Slack group is resolved. https://expensify.slack.com/archives/C01GTK53T8Q/p1730857949391549

[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.60-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix prevent brief hiding of Expense preview when returning to report … #52119

If no regressions arise, payment will be issued on 2024-11-20. 🎊

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

• @huult requires payment automatic offer (Contributor)
• @fedirjh requires payment through NewDot Manual Requests

[melvin-bot]

Issue is ready for payment but no BZ is assigned. @RachCHopkins you are the lucky winner! Please verify the payment summary looks correct and complete the checklist. Thanks!

[melvin-bot]

@francoisl, @huult, @RachCHopkins, @fedirjh Whoops! This issue is 2 days overdue. Let's get this updated quick!

[fedirjh]

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
• 2b. Reported on staging (deploy blocker)
• 2c. Reported on both staging and production
• 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: [HOLD for payment 2024-11-20] [$250] Expense-Expense preview is hidden briefly when returning to expense report via header subtitle #49741 (comment)

• [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: N/A

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

  N/A This was a deploy blocker, So I believe this flow was already covered.

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:

Do we agree 👍 or 👎

[huult]

@RachCHopkins @francoisl Sorry, I still have not received the payment. Can you help me check? Maybe we have an issue with Upwork?

[melvin-bot]

@francoisl, @huult, @RachCHopkins, @fedirjh Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[francoisl]

@RachCHopkins are you available to help with the payments here please?

[RachCHopkins]

I sure am! Sorry guys, my fancy zap malfunctioned and I didn't see the ping! I'll get this sorted out asap.

[RachCHopkins]

Payment Summary:

• Contributor: @huult to be paid $250 via Upwork
• Contributor+: @fedirjh to be paid $250 via NewDot Manual Request

Upwork job here

[RachCHopkins]

Contributor has been paid, the contract has been completed, and the Upwork post has been closed.

[garrettmknight]

$250 approved for @fedirjh