Repository navigation
[HOLD for payment 2024-10-24] [$250] Report -Approval button is loaded indefinitely after payment of the report with hold expense #48999
Description
Activity
Triggered auto assignment to @muttmuure (
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.We think that this bug might be related to #wave-collect - Release 1
@muttmuure 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
Edited by proposal-police: This proposal was edited at 2024-09-12 07:47:49 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
Approval button is loaded indefinitely after payment of the report with hold expense
What is the root cause of that problem?
We display the loading state based on
canAllowSettlementcheck
In this function, we have this check
hasOptimisticHeldExpense. When we approve only unhold expenses, all transactions of the new expense report are held but we don't updateunheldTotalin optimistic data then this check is alwaystruewhich causes the approve button loading infinitely until we open the expense report or reload to get theunheldTotalof expense report from BE.Line 7184 in 336e478
What changes do you think we should make in order to solve the problem?
We can update exactly
unheldTotalof new expense report to0in optimistic data when we build the onyx data here since all transactions are heldonyxMethod: Onyx.METHOD.MERGE, key: `${ONYXKEYS.COLLECTION.REPORT}${optimisticExpenseReport.reportID}`, value: { ...optimisticExpenseReport, unheldTotal: 0, },Lines 6460 to 6461 in 336e478
OPTIONAL: We can accept
unheldTotalparam inbuildOptimisticExpenseReportfunction. If it is undefined, we will update this field astotalparam otherwise useunheldTotalparam. Then pass this param as0when we build the optimistic data here.What alternative solutions did you explore? (Optional)
NA
@muttmuure Eep! 4 days overdue now. Issues have feelings too...
Job added to Upwork: https://www.upwork.com/jobs/~021836106125438284178
- changed the title
[-]Report -Approval button is loaded indefinitely after payment of the report with hold expense[/-][+][$250] Report -Approval button is loaded indefinitely after payment of the report with hold expense[/+]on Sep 17, 2024 Triggered auto assignment to Contributor-plus team member for initial proposal review - @akinwale (
External)21 remaining items
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.49-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2024-10-24. 🎊
For reference, here are some details about the assignees on this issue:
- @akinwale requires payment automatic offer (Reviewer)
- @nkdengineer requires payment automatic offer (Contributor)
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:
- [@akinwale] The PR that introduced the bug has been identified. Link to the PR:
- [@akinwale] 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:
- [@akinwale] 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:
- [@akinwale] Determine if we should create a regression test for this bug.
- [@akinwale] 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.
- [@muttmuure] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:
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:
- [@akinwale] The PR that introduced the bug has been identified. Link to the PR:
- [@akinwale] 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:
- [@akinwale] 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:
Not a regression.
- [@akinwale] Determine if we should create a regression test for this bug.
- [@akinwale] 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.
Regression Test Steps
- Launch 2 instances of Expensify
- Log in as an approver of a workspace on one instance, and as an employee of the same workspace on the other instance
- As employee: Navigate to the report with two duplicate expenses
- As employee: Hold one of the expenses
- As approver: Approve the pending amount on the non-held expense
- As approver: Navigate back to the room by clicking on the header
- Verify that the approval button is displayed after payment of the report containing the held expense.
Do we agree 👍 or 👎?
Not a regression.
If this isn't a regression, was it just something missed or a bug in the original feature?
@tgolen, @akinwale, @muttmuure, @nkdengineer Huh... This is 4 days overdue. Who can take care of this?
Not a regression.
If this isn't a regression, was it just something missed or a bug in the original feature?
It's more likely something that was missed with the checks for
unheldTotal. I wasn't able to find a recent change that introduced the issue.OK, thank you! I'll let @muttmuure finish this one up then. I think it's ready to be closed.
All paid up
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.32-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: https://expensify.testrail.io/index.php?/tests/view/4947393
Email or phone of affected tester (no customers): sustinov@applausemail.com
Issue reported by: Applause Internal Team
Action Performed:
Prerequisites:
Create 3 accounts Admin, Approver, Employee. Create WS as Admin, add two members Approver, Employee. In Workflow, add the Approver member as an expense approver. On behalf of Employee, send two expenses to the WS room.
Steps:
Expected Result:
The approval button should load immediately after payment of the report with hold expense
Actual Result:
Approval button is loaded indefinitely after payment of the report with hold expense
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Bug6600082_1726067654233.Recording__154.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @muttmuure