[$250] Web - Chat - Temporary thread message disappearance when deleting a thread message
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:
- Go to https://staging.new.expensify.com/
- Open a chat
- Send a message in the chat
- Click on "Reply in thread" to create a thread message
- 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
https://github.com/user-attachments/assets/3c526c02-1b86-4831-8557-40220d894b0d
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: @thesahindia
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.
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 https://github.com/Expensify/App/pull/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]:
https://github.com/Expensify/App/blob/77b483c50f3669540fa37b530afd87ba709baf3a/src/libs/actions/Report.ts#L1433
https://github.com/Expensify/App/blob/e05545549299f2f0ce6117cbfb62b97fbf15d39a/src/pages/home/report/ReportActionItemFragment.tsx#L108-L110
What changes do you think we should make in order to solve the problem?
Let's hold this for https://github.com/Expensify/App/pull/51721 where they introduced isThreadFirstChat prop. This will help determining isDeletedParentAction based on whether it is rendered by ReportActionItemParentAction instead of relying on reportID.
@JmillsExpensify Huh... This is 4 days overdue. Who can take care of this?
Low priority but we have two proposals outstanding, so I'm going to open this up to the community.
Job added to Upwork: https://www.upwork.com/jobs/~021856693071374545175
Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)
Let's hold this for #51721 where they introduced
isThreadFirstChatprop. This will help determiningisDeletedParentActionbased on whether it is rendered byReportActionItemParentActioninstead of relying onreportID.
Waiting on ^
@JmillsExpensify, @thesahindia Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@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!
@JmillsExpensify, @thesahindia Huh... This is 4 days overdue. Who can take care of this?
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
@JmillsExpensify, @thesahindia 6 days overdue. This is scarier than being forced to listen to Vogon poetry!
@mkzie2, the PR has been merged.
@JmillsExpensify, @thesahindia Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
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 https://github.com/Expensify/App/pull/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...:
https://github.com/Expensify/App/blob/cfc41bc42ba95bd6928d4e2456c460f6366e0c43/src/pages/home/report/ReportActionItem.tsx#L1015
... until pendingAction is cleared by the BE:
https://github.com/Expensify/App/blob/be6acac6f051b290d96e14353704065e4928b53a/src/components/OfflineWithFeedback.tsx#L94
What changes do you think we should make in order to solve the problem?
Thanks to https://github.com/Expensify/App/pull/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}
@thesahindia Part of the root cause is still correct but I adjusted the solution. Please check again.
Still working through proposals
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
Triggered auto assignment to @marcochavezf, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@JmillsExpensify @marcochavezf @thesahindia this issue is now 4 weeks old, please consider:
- Finding a contributor to fix the bug
- Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
- If you have any questions, don't hesitate to start a discussion in #expensify-open-source
Thanks!
Waiting for assignment from @marcochavezf.
Thanks for the review @thesahindia! Assigning @mkzie2 π
π£ @mkzie2 π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
@thesahindia The PR is here.
Reviewing label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.74-8 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
- https://github.com/Expensify/App/pull/53733
If no regressions arise, payment will be issued on 2024-12-19. :confetti_ball:
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)
@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]
Payment summary:
- Contributor: $250 for @mkzie2 via Upwork
- Reviewer: $250 for @thesahindia via New Expensify
Contributor has been paid out.