[HOLD for payment 2024-07-22] [HOLD for payment 2024-07-17] [regession] [$500] RBR transaction thread is disappearing from the LHN when navigating to another chat

[m-natarajan]

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.42-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @puneetlath
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1708116749863699

Action Performed:

1. have an expense that you are the submitter on, which has violations
2. go to the transaction thread
3. notice that you see violations on the expense and that the RBR is shown in the LHN
4. navigate to a different chat

Expected Result:

the RBR chat stays "pinned" in the LHN as long as the RBR is present

Actual Result:

the chat disappears from the LHN

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

Recording.2748.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0198d221d75f59ca56
• Upwork Job ID: 1759384231310438400
• Last Price Increase: 2024-04-23
• Automatic offers:
• jjcoffee | Reviewer | 0
• tienifr | Contributor | 0

Issue Owner

Current Issue Owner: @stephanieelliott / @stephanieelliott

Issue Owner

Current Issue Owner: @stephanieelliott

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[tienifr]

Proposal

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

The chat disappears from the LHN

What is the root cause of that problem?

In here, we're not prioritize showing the errored report, so it will disappear if we navigate to another report because it doesn't meet the filtering criteria.

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

1. In here, we're having a logic to make sure hasErrorsOtherThanFailedReceipt will override the isHidden, meaning if hasErrorsOtherThanFailedReceipt is true, even though isHidden is true, it will not early-filter-out the report, however this doesn't guarantee that the errored report will be included in the list, because it could still fail the check here.

To make sure errored report will always show, in here, we should add logic to always include errored report in the reportsToDisplay list in LHN:

if (hasErrorsOtherThanFailedReceipt) {
    return true;
}

2. This will make sure the errored report show, but it will show in arbitrary order because it will be grouped in the nonArchivedReports list. If we want those errored reports to always show on top, we can add logic to get those reports (similar to the condition hasErrorsOtherThanFailedReceipt above) and group it in a list (like the pinned/GBR reports) and push in here (where it's ordered can be decided by design team, but I think it can be after the pinnedAndGBRReports)

The above is general approach, the specific logic to check if the report has errors, ... can be polished if needed.

What alternative solutions did you explore? (Optional)

In 1., if there're cases where the errored report should not show, we should pass the hasErrorsOtherThanFailedReceipt into shouldReportBeInOptionList and do early return inside shouldReportBeInOptionList, where the priority that we determined (there're 10+ cases inside there so we need to determine which case hasErrorsOtherThanFailedReceipt should override and which case it should not)

We can group the errored reports inside pinnedAndGBRReports itself by adding another condition here, so it will consider RBR similar to GBR.

[youssef-lr]

This is getting fixed in #33029. So I think we should hold this one.

[stephanieelliott]

Still on hold for #33029.

[stephanieelliott]

#33029 is on prod now! @m-natarajan can you please retest for us?

[mvtglobally]

Issue is reproducible during KI retests.
https://platform.applause.com/services/links/v1/external/0f18d29bd4aff3922804c80bcae5f2205e699b8b5f9c91f36d659bc6d54f458f

[jjcoffee]

I guess we can re-hold on #33029 since the PR was reverted due to performance issues?

[stephanieelliott]

Applying the New Feature label to get another BZ member on this while I am OOO til July 10. To catch you up on where we are @puneetlath: this issue caused a regression which was fixed by PR #43502. That PR should be deployed to staging soon -- once it hits prod you'll want to update this issue's title with the new payment date.

Thanks for watching this, I'll grab this back from you when I return!

[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 automatic offer (Reviewer)
• @tienifr requires payment automatic offer (Contributor)

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

• [@puneetlath / @AndrewGable] The PR that introduced the bug has been identified. Link to the PR:
• [@puneetlath / @AndrewGable] 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:
• [@puneetlath / @AndrewGable] 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.
• [@stephanieelliott] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[mallenexpensify]

@stephanieelliott , @tienifr won't be paid on this issue due to a double payment on #38054 (comment)

[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 automatic offer (Reviewer)
• @tienifr requires payment automatic offer (Contributor)

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

• [@AndrewGable] The PR that introduced the bug has been identified. Link to the PR:
• [@AndrewGable] 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:
• [@AndrewGable] 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.
• [@stephanieelliott] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[mallenexpensify]

Contributor: @tienifr not paid $500 due to a double payment on #38054 (comment)
Contributor+: @jjcoffee paid $500 via Upwork.

@jjcoffee can you fill out the BZ checklist above? thx

[jjcoffee]

• The PR that introduced the bug has been identified. Link to the PR: N/A - this was just never implemented
• 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: N/A
• 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: N/A
• Determine if we should create a regression test for this bug. Yes - we have multiple we need to add
• 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.

Regression Test Proposal

Test 1

1. Have an expense that you are the submitter on, which has violations
2. Go to the transaction thread
3. Notice that you see violations on the expense and that the RBR is shown in the LHN
4. Navigate to a different chat
5. Verify the RBR chat remains in the LHN as long as the RBR is present

Test 2

1. Go to a workspace chat that has no unsettled expense.
2. Create an expense that will induce RBR (e.g. on a workspace where category is required submit an expense without category).
3. Click on the report with RBR on LHN.
4. Click on the header subtitle.
5. Verify app will return to the workspace main chat.

Test 3

Prerequisite: User A and B have no chatted before and both accounts are new.

1. [User A] Go offline
2. [User A] Submit an expense to User B
3. [User B] Submit an expense with the same amount to User A
4. [User A] Go online
5. Verify user A will not have two same transaction threads with RBR on LHN.

Do we agree 👍 or 👎

[melvin-bot]

@AndrewGable, @jjcoffee, @stephanieelliott, @tienifr Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[stephanieelliott]

Thanks @jjcoffee! Issue for test case here: https://github.com/Expensify/Expensify/issues/415683