[HOLD for payment 2024-05-22] [$250] Web - IOU - Unable to delete replaced receipt on manual request

[kavimuru]

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: 1.4.63-0 Reproducible in staging?: y Reproducible in production?: y If this was caught during regression testing, add the test name, ID and link from TestRail: N/A 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 any chat> Create manual request
2. Go to detail IOU page> Add receipt
3. Go to 3-dots menu and replace the receipt
4. Go to 3-dots menu and select Delete

Expected Result:

Receipt should be deleted

Actual Result:

Unable to delete replaced receipt on manual request when there is one request

Workaround:

unknown

Platforms:

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

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [ ] iOS: Native
• [ ] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/43996225/94973ab8-d886-43cf-8701-d8246593a9e6

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01bd5a6adff9415feb
• Upwork Job ID: 1782709161350098944
• Last Price Increase: 2024-04-23
• Automatic offers:
• nkdengineer | Contributor | 0

Issue Owner

Current Issue Owner: @anmurali

[melvin-bot[bot]]

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

[kavimuru]

@anmurali 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.

[kavimuru]

This bug might be related to #wave-collect - Release 1

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[nkdengineer]

Proposal

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

Unable to delete replaced receipt on manual request when there is one request

What is the root cause of that problem?

The back-end is returning 405 Cannot detach receipt from unowned transaction, and we're simply restoring the transaction here without showing any error message to the user.

So from the user POV, the receipt just restores itself and the feature looks like it doesn't work.

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

1. In here https://github.com/Expensify/App/blob/f28d401b33649e25512cdc88efd4d7d0d944ab5f/src/libs/actions/IOU.ts#L5757, we should set errors on the transaction if the receipt deletion fails. We can add a new error message key like Unexpected error deleting this receipt. Please try again later.

value: {
    ...transaction,
    errors: ErrorUtils.getMicroSecondOnyxError('iou.error.receiptDeleteFailureError')
},

We already have it for the replaceReceipt case, and when requesting money, just missing it for the delete receipt case.

We can also remove the error in optimistic/success data.

2. Fix the back-end not to error in this case, because it's a valid case.

What alternative solutions did you explore? (Optional)

NA

[melvin-bot[bot]]

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

[allroundexperts]

@nkdengineer's proposal looks good to me. In this case, we'd need someone on the backend to fix the error. Regardless of that, as mentioned in the proposal, we should show the error and that would require a fix from the frontend.

🎀 👀 🎀 C+ reviewed

[melvin-bot[bot]]

Triggered auto assignment to @MariaHCD, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[MariaHCD]

I agree that we need to show an error message if deleting a receipt on a request does not succeed 👍🏼

[melvin-bot[bot]]

📣 @nkdengineer 🎉 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 📖

[MariaHCD]

Looking into the backend error and leaving some notes for myself.

We're throwing the error here

Logs from testing locally

``` 2024-04-29T07:44:01.472184+00:00 expensidev2004 bedrock: USMjjb test@iouaccount.com (Transaction.cpp:46) verifyWrite [sync] [info] Transaction::verifyWrite accountID=9684 transactionIDList=9166041848027912271 maxReportState=0 isValidOwner=1 areOnValidReports=0 2024-04-29T07:44:01.472366+00:00 expensidev2004 bedrock: USMjjb test@iouaccount.com (Receipt.cpp:65) attach [sync] [info] [ReceiptAttach] write/own accountID=9684 receiptID=0 transactionID=9166041848027912271 verifyWrite=0 managerOrAdminAttach=1 scraperMergeAttach=0 isAttachedToPartialTransaction=0 ```

I believe it's because of this condition. Spinning up a PR.

[MariaHCD]

Backend fix is out for review - https://github.com/Expensify/Auth/pull/10712

[MariaHCD]

Still working on the backend PR - https://github.com/Expensify/Auth/pull/10712

[MariaHCD]

@nkdengineer I believe you can proceed with the frontend PR while the backend piece is being worked on.

[nkdengineer]

@MariaHCD Thanks for your update, I will raise the PR soon.

[nkdengineer]

@allroundexperts The PR is here.

[MariaHCD]

The backend PR has been merged and will be deployed later today: https://github.com/Expensify/Auth/pull/10712

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

If no regressions arise, payment will be issued on 2024-05-22. :confetti_ball:

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

• @allroundexperts requires payment through NewDot Manual Requests
• @nkdengineer requires payment automatic offer (Contributor)

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

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