[HOLD for payment 2024-07-10] [HOLD for payment 2024-07-02] Expense - Expense report shows a blank message instead of "detached a receipt from expense"

[m-natarajan]

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: 9.0.1.0
Reproducible in staging?: y
Reproducible in production?: no new feature
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 DM.
3. Submit two expenses to the user - one of the expenses must be submitted with a receipt.
4. Go to Troubleshoot > Clear cache and restart > Reset and refresh.
5. Go to the same DM in Step 2.
6. Go to transaction thread of expense with receipt.
7. Click on the receipt.
8. Click 3-dot menu > Delete receipt > Delete the receipt.
9. Go to expense report.

Expected Result:

"detached a receipt from expense" system message will be visible in the expense report.

Actual Result:

"detached a receipt from expense" system message is not visible in the expense report.
The message is blank in the report. It only displays the message in LHN preview.

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

Bug6521472_1719064301749.20240622_201403.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @greg-schroeder

[melvin-bot]

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

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

[melvin-bot]

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

[m-natarajan]

@grgia 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

[m-natarajan]

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

[tsa321]

Proposal

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

Expense - Expense report shows a blank message instead of "detached a receipt from expense" when user delete receipt.

What is the root cause of that problem?

When user remove receipt, the server will return report action with type: MANAGERDETACHRECEIPT. and it is categorized as old dot report action:

App/src/libs/ReportActionsUtils.ts

Line 1162 in 4dc1710

function isOldDotReportAction(action: ReportAction): boolean {

In PR: #40168 getMessageOfOldDotReportAction got modified:

App/src/libs/ReportActionsUtils.ts

Lines 1199 to 1203 in 4dc1710

	function getMessageOfOldDotReportAction(reportAction: OnyxEntry<ReportAction>): string {
	if (!Array.isArray(reportAction?.message)) {
	return getReportActionText(reportAction);
	}
	return reportAction?.message?.map((element) => getTextFromHtml(element?.html)).join('') ?? '';

The content of reportActions is:

And will make the getMessageOfOldDotReportAction give incorrect result.

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

If this is deploy blocker:
We should modify the getMessageOfOldDotReportAction into:

function getMessageOfOldDotReportAction(reportAction: OnyxEntry<ReportAction>): string {
    return reportAction?.message?.map((element) => getTextFromHtml(element?.text)).join('') ?? '';
}

[melvin-bot]

Current assignee @grgia is eligible for the DeployBlockerCash assigner, not assigning anyone new.

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

[deetergp]

I'm pretty sure this is caused by this PR — particularly the changes to ReportActionUtils.getMessageOfOldDotReportAction

[tsa321]

@deetergp yes, the fix is to revert the getMessageOfOldDotReportAction into:

function getMessageOfOldDotReportAction(reportAction: OnyxEntry<ReportAction>): string {
    return reportAction?.message?.map((element) => getTextFromHtml(element?.text)).join('') ?? '';
}

[greg-schroeder]

cc @nkdengineer

[nkdengineer]

checking this now.

[nkdengineer]

cc @c3024 The PR is ready.

[deetergp]

This should be fixed now. I have asked for a retest here.

[kavimuru]

@deetergp issue fixed

20240625_233359.mp4

[deetergp]

Since the bug is fixed I'm going to close this one out. Thanks all 👋

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

• [CP Staging] Fix regression when html doesn't exist #44365

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

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

• [@deetergp] The PR that introduced the bug has been identified. Link to the PR:
• [@deetergp] 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:
• [@deetergp] 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:
• [@deetergp] Determine if we should create a regression test for this bug.
• [@deetergp] 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.
• [@greg-schroeder] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

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

• [CP Staging] Fix regression when html doesn't exist #44365

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

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

• [@deetergp] The PR that introduced the bug has been identified. Link to the PR:
• [@deetergp] 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:
• [@deetergp] 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:
• [@deetergp] Determine if we should create a regression test for this bug.
• [@deetergp] 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.
• [@greg-schroeder] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: