[HOLD for payment 2024-07-22] [HOLD for payment 2024-07-17] Expense - Header subtitle from report with RBR in LHN leads to the same transaction view

[kavimuru]

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: 1.4.80-9
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):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat that has no unsettled expense.
3. Create an expense that will induce RBR (make category in expense a requirement and submit an expense without category).
4. Click on the report with RBR on LHN.
5. Click on the header subtitle.

Expected Result:

App will return to the workspace main chat.

Actual Result:

App returns to the same transaction view.
This issue only happens when there is one expense in the workspace chat.

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

Bug6504503_1717721486593.20240607_084820.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @kevinksullivan

[melvin-bot]

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

[kavimuru]

@marcaaron FYI 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.

[kavimuru]

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

[marcaaron]

I am not really convinced this needs to be a blocker.

[marcaaron]

@roryabraham lmk if you agree. I'm heading OOO so a volunteer will need to give this another look tomorrow.

[bernhardoj]

The transaction thread shouldn't be shown in the LHN because we hide it if it's a one transaction thread.

App/src/libs/ReportUtils.ts

Lines 5320 to 5323 in 1426c4e

	// If this is a transaction thread associated with a report that only has one transaction, omit it
	if (isOneTransactionThread(report.reportID, report.parentReportID ?? '0')) {
	return false;
	}

But #41507 changes the behavior that every report that has error is shown.

[jjcoffee]

Hmm #41507 hasn't hit staging yet though.

[bernhardoj]

Oh, you're right. The reportID comparison here fails because reportID is a string but transactionThreadReportID is a number. transactionThreadReportID is from the money request action childReportID which supposed to be a string, so it's a BE problem.

App/src/libs/ReportUtils.ts

Lines 1444 to 1447 in 4fcc5a9

	function isOneTransactionThread(reportID: string, parentReportID: string): boolean {
	const parentReportActions = allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID}`] ?? ([] as ReportAction[]);
	const transactionThreadReportID = ReportActionsUtils.getOneTransactionThreadReportID(parentReportID, parentReportActions);
	return reportID === transactionThreadReportID;

App/src/types/onyx/ReportAction.ts

Line 161 in 4fcc5a9

childReportID?: string;

But even after we fix it, one transaction thread will still show because of this code.

App/src/libs/SidebarUtils.ts

Lines 97 to 103 in 4fcc5a9

	if (hasErrorsOtherThanFailedReceipt) {
	reportsToDisplay.push({
	...report,
	hasErrorsOtherThanFailedReceipt: true,
	});
	return;
	}

[trjExpensify]

@jjcoffee do you agree with that assessment that there's a BE error here?

[luacmartins]

@jjcoffee I do see #41507 in the staging checklist and I also see that PR's code on the staging branch.

[luacmartins]

TBH I think this is expected? When we have a single transaction report, the view for the thread and the expense report are the same? @trjExpensify can you confirm?

[jjcoffee]

@luacmartins Oh my bad, I was going by the QA ongoing comment on the PR! There must be something wrong with the automation.

But yeah I agree that this is expected, the header link being tapped is to the Expense Report, so the expected result of being navigated to the workspace is incorrect.

[luacmartins]

@trjExpensify and I discussed this internally, and we think the behavior introduced in #41507 might be slightly incorrect. For the one expense report, we should be pinning the expense report, not the thread for that expense.

[luacmartins]

I'm gonna demote this to NAB since nothing is broken, but we should fix the expected behavior here. cc @tienifr @jjcoffee @AndrewGable @cead22

[jjcoffee]

@luacmartins Do you think we should fix the BE issue mentioned here first? @tienifr is currently looking at converting to string in the comparison here:

App/src/libs/ReportUtils.ts

Lines 1444 to 1447 in 4fcc5a9

	function isOneTransactionThread(reportID: string, parentReportID: string): boolean {
	const parentReportActions = allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID}`] ?? ([] as ReportAction[]);
	const transactionThreadReportID = ReportActionsUtils.getOneTransactionThreadReportID(parentReportID, parentReportActions);
	return reportID === transactionThreadReportID;

i.e.: reportID?.toString() === transactionThreadReportID?.toString();

[luacmartins]

Yea, we should also fix this in the backend. Do we know which API command is returning it as an int instead of string?

[tienifr]

@jjcoffee we should be showing the expense report in this case, so the header should show the workspace chat and tapping it would lead the user to the workspace chat, instead of showing/navigating to the expense report like we're doing. So we have:
Workspace chat > Expense report > Transaction thread (we're showing this now)
Workspace chat > Expense report (we should show this instead) > Transaction thread (not accessible for 1 expense report)

@luacmartins Should we display the RBR in the expense report in case of one transaction? In the video in this bug, we do not. cc @jjcoffee as you requested that feature here.

[luacmartins]

Yes, the RBR should be shown for the expense report in that case.

[luacmartins]

Also, bump on this comment

[tienifr]

@luacmartins Based on this comment, when we call RequestMoney api, the money request action childReportID is number instead of string.

[luacmartins]

Thanks! I put up a PR to fix that and return childReportID as a string.

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

• fix RBR transaction thread is disappearing from the LHN when navigating to another chat v2 #43502

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

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

• @jjcoffee requires payment (Needs manual offer from BZ)
• @tienifr requires payment through NewDot Manual Requests

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@luacmartins] The PR that introduced the bug has been identified. Link to the PR:
• [@luacmartins] 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:
• [@luacmartins] A discussion in #expensify-bugs 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:
• [@jjcoffee / @tienifr] Determine if we should create a regression test for this bug.
• [@jjcoffee / @tienifr] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@kevinksullivan] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[jjcoffee]

Note that payment is not required here, it will be handled on #36778.

[luacmartins]

Thanks for pointing that out. I think we're good to close then!

[melvin-bot]

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

• fix RBR transaction thread is disappearing from the LHN when navigating to another chat v2 #43502

If no regressions arise, payment will be issued on 2024-07-22. 🎊

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

• @jjcoffee requires payment (Needs manual offer from BZ)
• @tienifr requires payment through NewDot Manual Requests

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@luacmartins] The PR that introduced the bug has been identified. Link to the PR:
• [@luacmartins] 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:
• [@luacmartins] A discussion in #expensify-bugs 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:
• [@jjcoffee / @tienifr] Determine if we should create a regression test for this bug.
• [@jjcoffee / @tienifr] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@kevinksullivan] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: