[HOLD for payment 2024-12-19] [$250] Web - Chat - Temporary thread message disappearance when deleting a thread message

[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.58-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Open a chat
3. Send a message in the chat
4. Click on "Reply in thread" to create a thread message
5. Delete the threaded message

Expected Result:

A thread message should remain visible and not disappear after deleting it

Actual Result:

When the user deletes a thread message, it disappears for a short while and then reappears

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6645785_1729876009195.23139.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021856693071374545175
• Upwork Job ID: 1856693071374545175
• Last Price Increase: 2024-11-27
• Automatic offers:
• mkzie2 | Contributor | 105206412

Issue Owner

Current Issue Owner: @JmillsExpensify

[melvin-bot]

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

[mkzie2]

Proposal

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

When the user deletes a thread message, it disappears for a short while and then reappears

What is the root cause of that problem?

This arises from #43518, the reportID now contains the reportID of the report where the action belongs to (the ancestor tree is lifted 1 level above).

So when we delete the comment, reportID does not point to the current thread report >> isDeletedParentAction is false because it compares the reportID with childReportID >> Comment is hidden instead of [Deleted message]:

App/src/libs/actions/Report.ts

Line 1433 in 77b483c

const isDeletedParentAction = ReportActionsUtils.isThreadParentMessage(reportAction, reportID);

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

Lines 108 to 110 in e055455

	if ((!isOffline && isThreadParentMessage && isPendingDelete) || fragment?.isDeletedParentAction) {
	return <RenderHTML html={`<comment>${translate('parentReportAction.deletedMessage')}</comment>`} />;
	}

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

Let's hold this for #51721 where they introduced isThreadFirstChat prop. This will help determining isDeletedParentAction based on whether it is rendered by ReportActionItemParentAction instead of relying on reportID.

[melvin-bot]

@JmillsExpensify Huh... This is 4 days overdue. Who can take care of this?

[JmillsExpensify]

Low priority but we have two proposals outstanding, so I'm going to open this up to the community.

[melvin-bot]

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

[melvin-bot]

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

[thesahindia]

Let's hold this for #51721 where they introduced isThreadFirstChat prop. This will help determining isDeletedParentAction based on whether it is rendered by ReportActionItemParentAction instead of relying on reportID.

Waiting on ^

[melvin-bot]

@JmillsExpensify, @thesahindia Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@JmillsExpensify @thesahindia this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@JmillsExpensify, @thesahindia Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

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

[melvin-bot]

@JmillsExpensify, @thesahindia 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[thesahindia]

@mkzie2, the PR has been merged.

[melvin-bot]

@JmillsExpensify, @thesahindia Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mkzie2]

Edited by proposal-police: This proposal was edited at 2024-11-26 10:45:35 UTC.

Updated Proposal

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

When the user deletes a thread message, it disappears for a short while and then reappears

What is the root cause of that problem?

This arises from #43518, the reportID now contains the reportID of the report where the action belongs to (the ancestor tree is lifted 1 level above).

So when we delete the comment, reportID does not point to the current thread report >> isThreadParentMessage is false because it compares the reportID with childReportID >> shouldHideOnDelete is true causing the message to be hidden for a while...:

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

Line 1015 in cfc41bc

shouldHideOnDelete={!ReportActionsUtils.isThreadParentMessage(action, reportID)}

... until pendingAction is cleared by the BE:

App/src/components/OfflineWithFeedback.tsx

Line 94 in be6acac

const hideChildren = shouldHideOnDelete && !isOffline && pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && !hasErrors;

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

Thanks to #51721, we don't rely on reportID to check for isThreadParentMessage which is no longer correct. Instead, we use isThreadReportParentAction which is based on whether the action is rendered by ReportActionItemParentAction.

So we need to update:

shouldHideOnDelete={!isThreadReportParentAction}

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

• Fix temporary thread message disappear #53733

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

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

• @thesahindia requires payment through NewDot Manual Requests
• @mkzie2 requires payment automatic offer (Contributor)

[melvin-bot]

@thesahindia @JmillsExpensify @thesahindia 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]

[JmillsExpensify]

Payment summary:

• Contributor: $250 for @mkzie2 via Upwork
• Reviewer: $250 for @thesahindia via New Expensify

[JmillsExpensify]

Contributor has been paid out.

[melvin-bot]

@JmillsExpensify, @marcochavezf, @thesahindia, @mkzie2 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@JmillsExpensify, @marcochavezf, @thesahindia, @mkzie2 Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@JmillsExpensify, @marcochavezf, @thesahindia, @mkzie2 Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[melvin-bot]

@JmillsExpensify, @marcochavezf, @thesahindia, @mkzie2 10 days overdue. Is anyone even seeing these? Hello?

[melvin-bot]

@JmillsExpensify, @marcochavezf, @thesahindia, @mkzie2 12 days overdue now... This issue's end is nigh!

[melvin-bot]

This issue has not been updated in over 14 days. @JmillsExpensify, @marcochavezf, @thesahindia, @mkzie2 eroding to Weekly issue.

[thesahindia]

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: Reinstate fix get all ancestors in a thread #43518 (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.

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

Test:

1. Open any report
2. Send a message
3. Reply in thread
4. Click on parent report action and delete the message
5. Verify that the report action doesn't disappear
6. Verify you see [Deleted message]

Do we agree 👍 or 👎

[thesahindia]

@JmillsExpensify, could you please add the payment summary?

[JmillsExpensify]

Are you referring to this one?

[JmillsExpensify]

Closing this out though now that the BZ summary is complete.