[HOLD for payment 2023-04-26] [$1000] Red dot remains visible on chat after a failed attachment is deleted

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Click on “Profile” avatar
2. Click on “Preference” link
3. Turn on “Simulate a network failure”
4. Open an existing chat
5. Click on “Actions” icon
6. Click on “Add attachment” link
7. Select a picture of file
8. Wait few seconds
9. Turn off “Simulate a network failure”
10. Click on “Delete” icon on the failed attachment
11. Observe that the failed attachment is deleted, and the corresponding error indicator ‘Red dot’ remains visible on the chat

Expected Result:

Red dot shouldn’t remain visible after a filed attachment is deleted

Actual Result:

Red dot remains visible after a failed attachment is deleted

Workaround:

unknown

Platforms:

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

• [ ] Android / native
• [ ] Android / Chrome
• [ ] iOS / native
• [ ] iOS / Safari
• [x] MacOS / Chrome / Safari
• [ ] MacOS / Desktop

Version Number: 1.2.93-4 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 Notes/Photos/Videos: Any additional supporting documentation

https://user-images.githubusercontent.com/43996225/229311733-d3e450eb-e37c-49b9-845e-399efde391b0.mp4

https://user-images.githubusercontent.com/43996225/229311740-f7a68b5f-2489-44e8-97a9-995256351019.mp4

Expensify/Expensify Issue URL: Issue reported by: @Natnael-Guchima Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1680249331562699

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01365275cfe90a2203
• Upwork Job ID: 1643570634344288256
• Last Price Increase: 2023-04-12

[MelvinBot]

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

[MelvinBot]

Bug0 Triage Checklist (Main S/O)

• [x] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• [x] This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• [x] This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• [x] This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• [x] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[MelvinBot]

@bfitzexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[bfitzexpensify]

Think this is valid for external

[MelvinBot]

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

[MelvinBot]

Current assignee @bfitzexpensify is eligible for the External assigner, not assigning anyone new.

[MelvinBot]

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

[MelvinBot]

Triggered auto assignment to @neil-marcellini (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[bernhardoj]

Proposal

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

Red dot in LHN (chat) item still shows after deleting the report action that cause the error indicator.

What is the root cause of that problem?

When we delete a report action, we never clear the errors. https://github.com/Expensify/App/blob/4ee21e95a38858df28e46caf54dc97e1bca9bc7a/src/libs/actions/Report.js#L706-L712

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

Add errors: null to clear the error in optimistic data and errors: reportAction.errors in failure data to revert the errors just in case the request fails. https://github.com/Expensify/App/blob/4ee21e95a38858df28e46caf54dc97e1bca9bc7a/src/libs/actions/Report.js#L725-L737

[bfitzexpensify]

Not overdue, melv

[tienifr]

Proposal

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

Red dot remains visible after a failed attachment is deleted.

What is the root cause of that problem?

The root cause is here where we're getting the errors of the report. We don't exclude deleted (or pending deleted) report actions here so after the (errored) report action is deleted, it will still show the red dot.

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

We need to add logic below this line https://github.com/Expensify/App/blob/62276baa62ffefbae4ccfc7ed5aacc61a7322737/src/libs/OptionsListUtils.js#L230 to filter only the report actions that are deleted (or pending deleted).

Then use that filtered list to calculate the list of errors of the report.

If we just set the errors to null when deleting the report action, it will not work for the case when we delete the report action from another device. This is because the errors is stored locally.

What alternative solutions did you explore? (Optional)

• Another potential solution is to set the errors to null in optimistic data (of course will need to restore it in case of request failure) when deleting the action. And also set the errors to null when we detect that the report action has been deleted (to make sure it still works when deleting the report action from another device), this can be done by putting the logic inside a ONYXKEYS.COLLECTION.REPORT_ACTIONS Onyx listener for example.
• While investigating this issue, I found another issue, not sure if it should be fixed in this GH but just mentioning for the sake of completeness: When there's error with posting the report action in 1st device, now the pendingAction is add, and then we delete that report action from a 2nd device. The report action will not disappear from the 1st device. This is because in here https://github.com/Expensify/App/blob/e3597c68d03ad48b50b328daf5cf3dbd269b678d/src/libs/ReportActionsUtils.js#L209 we still show the report action if the report action has any pendingAction. In this case it has pendingAction is add from the initial report action creating attempt so it still shows even though already deleted. To fix this we need to update the logic so that if the report action is deleted, it will only still show if the pendingAction is delete.

[bfitzexpensify]

Looks like we have a couple of proposals for you to review when you get a chance @0xmiroslav

[0xmiroslav]

sure, reviewing today

[MelvinBot]

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

[neil-marcellini]

@0xmiroslav says he's on it

[neil-marcellini]

I kind of like this proposal. It makes sense to remove the errors optimistically and restore them if deleting fails. Thoughts @0xmiroslav? Can you verify that we don't clear the errors in the response or Pusher data from deleting a comment?

[0xmiroslav]

I kind of like this proposal. It makes sense to remove the errors optimistically and restore them if deleting fails. Thoughts @0xmiroslav? Can you verify that we don't clear the errors in the response or Pusher data from deleting a comment?

That doesn't work as @tienifr reasoned in their proposal.

https://user-images.githubusercontent.com/97473779/231545388-ddc332a0-90fd-4904-9c0a-d91d2469e954.mov

[bernhardoj]

@0xmiroslav What is that don't work? If we want to handle when the user deleted the chat from other device, we should clear the errors from the Pusher.

[tienifr]

Also IMO the errors of an action and whether the action is deleted are not related to each other. So it might not be good to assume an action does not/did not have an error after it's deleted, it causes data loss. If we don't want to show it in the UI it might be better to filter it out.

[0xmiroslav]

@0xmiroslav What is that don't work? If we want to handle when the user deleted the chat from other device, we should clear the errors from the Pusher.

yeah I meant that. To apply your solution, backend should also be updated. We're discussing this internally since no such pattern of sending null error from backend yet. Will keep you updated.

[neil-marcellini]

If we just set the errors to null when deleting the report action, it will not work for the case when we delete the report action from another device.

@tienifr that doesn't make sense to me, because how would we see the report action (message) on another device if it failed to add? From my local testing, the simulate failing network requests toggle only simulates a failure, but the message actually posts. Since there's no consideration for other devices we can go with @bernhardoj's proposal and we won't need a backend change. Sound good @0xmiroslav?

[0xmiroslav]

@neil-marcellini Sounds good to me. Actually both "simulate network failure" and "delete failed attachment from another device" are edge cases which will most likely not happen on production for real users.

[neil-marcellini]

True the whole issue is an edge case, but if for some reason adding an attachment fails and the user decides to delete the comment rather than dismissing the error, we should clear the error. It's quite a simple front end change so we should do it.

[MelvinBot]

📣 @bernhardoj You have been assigned to this job by @neil-marcellini! Please apply to this job in Upwork 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 📖

[bernhardoj]

Thanks! Will open the PR in a few hours.

[MelvinBot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[MelvinBot]

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.1-3 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/17444

If no regressions arise, payment will be issued on 2023-04-26. :confetti_ball:

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• [x] External issue reporter
• [x] Contributor that fixed the issue
• [x] Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[MelvinBot]

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:

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

[bfitzexpensify]

Offers sent out for payment

[bfitzexpensify]

I think adding a regression test here is a good idea, perhaps in the Compose box - Attachment only (Offline Behavior) test