[HOLD #42118][$250] Expense status doesn't update after completing the action

[m-natarajan]

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.17-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:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @saracouto
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1722617920576379

Action Performed:

1. Submit an expense and get a violation
2. Fix the violation
3. Violation message doesn't update in the upper side of the screen

Expected Result:

Once the user clears the violation, the message should update from "Waiting for Sara Couto to fix the issue(s)" to the corresponding next step

Actual Result:

The message "Waiting for Sara Couto to fix the issue(s)" was still there even after fixing the violation

Workaround:

unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Recording.419.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01bfe746236df54daa
• Upwork Job ID: 1821182632521988875
• Last Price Increase: 2024-08-14
• Automatic offers:
• rayane-djouah | Reviewer | 103528411
• dominictb | Contributor | 103528413

Issue Owner

Current Issue Owner: @rayane-djouah

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[dominictb]

Edited by proposal-police: This proposal was edited at 2023-10-04 10:15:00.

Proposal

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

The message "Waiting for Sara Couto to fix the issue(s)" was still there even after fixing the violation

What is the root cause of that problem?

When we approve/submit money request, we'll generate the optimisticNextStep to show the user what will happen next:

App/src/libs/actions/IOU.ts

Line 6822 in 2200fd7

const optimisticNextStep = NextStepUtils.buildNextStep(expenseReport, CONST.REPORT.STATUS_NUM.APPROVED);

App/src/libs/actions/IOU.ts

Line 7066 in 2200fd7

const optimisticNextStep = NextStepUtils.buildNextStep(expenseReport, isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED);

However, when editing amount

App/src/libs/actions/IOU.ts

Line 5415 in 2200fd7

function updateMoneyRequestAmountAndCurrency({

, we're not doing that. Request edit can also lead to next step change, in case where there's violations and the violations are removed after the edit, and vice versa.

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

To fix it holistically for all money request update operations,
in here, first we check if the current transaction (before edits) has violations, next we check if the transaction after edit has violations. If the former is true and latter is false, that means the violations have been removed as the result of the edit, and the next step should be dependent on the expense report status now instead of "Wait for {user} to fix the issue(s)", so we'll buildNextStep like here with the status of the current expense report as the predictedNextStatus, and set it to Onyx just like we did for other flows.

const nextViolationOnyxUpdate = ViolationsUtils.getViolationsOnyxData(
                updatedTransaction,
                currentTransactionViolations,
                !!policy.requiresTag,
                policyTagList ?? {},
                !!policy.requiresCategory,
                policyCategories ?? {},
                PolicyUtils.hasDependentTags(policy, policyTagList ?? {}),
            );

// no more violation after update
if(currentTransactionViolations.length > 0 && nextViolationOnyxUpdate.value.length === 0) {
   const optimisticNextStep = NextStepUtils.buildNextStep(iouReport, iouReport.statusNum ?? CONST.REPORT.STATE_NUM.OPEN)
}

// update to onyx
optimisticData.push(nextViolationOnyxUpdate, {
    onyxMethod: Onyx.METHOD.SET,
    key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${iouReport?.reportID}`,
    value: optimisticNextStep,
})

failureData.push({
     onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${iouReport?.reportID}`,
    value:  currentReportNextStep // we can fetch the currentReportNextStep in in Onyx (ONYXKEYS.COLLECTION.NEXT_STEP) beforehand
})

What alternative solutions did you explore? (Optional)

We should at some point handle the case where "There's no violation before, but after edit there's violation", in that case the next step will be "Wait for {user} to fix the issue(s)". I think this is out of scope of this issue for now.

[dominictb]

Proposal updated to add notes in the alternative section

[rayane-djouah]

@dominictb - I think we should keep the "Wait for {user} to fix the issue(s)" next step message if we have optimistic violations returned from here:

App/src/libs/actions/IOU.ts

Line 5439 in 2200fd7

data = getUpdateMoneyRequestParams(transactionID, transactionThreadReportID, transactionChanges, policy ?? null, policyTagList ?? null, policyCategories ?? null, true);

App/src/libs/actions/IOU.ts

Lines 2691 to 2701 in 2200fd7

	optimisticData.push(
	ViolationsUtils.getViolationsOnyxData(
	updatedTransaction,
	currentTransactionViolations,
	!!policy.requiresTag,
	policyTagList ?? {},
	!!policy.requiresCategory,
	policyCategories ?? {},
	PolicyUtils.hasDependentTags(policy, policyTagList ?? {}),
	),
	);

We should change the next step message only if there are current transaction violations and there are no optimistic transaction violations. we need also to restore the next step in case of failure.

Could you please update your proposal and ping me again once it's ready for another review?

[dominictb]

We should change the next step message only if there are current transaction violations and there are no optimistic transaction violations. we need also to restore the next step in case of failure.

@rayane-djouah Hey sure that's what I meant by below point in my proposal, let me update with a bit more details in the proposal

we check if the current transaction (before edits) has violations, next we check if the transaction after edit has violations. If the former is true and latter is false

[trjExpensify]

Moving to #wave-control as it's optimistic next steps/violations related. CC: @dangrous @dylanexpensify

[dangrous]

assigning myself so I can take a look when proposals are approved!

[rayane-djouah]

@dominictb your proposal RCA and solution makes sense to me.

However, to fix the bug for all money request update flows, we need to make the changes in getUpdateMoneyRequestParams instead of making them only in updateMoneyRequestAmountAndCurrency function as all the edit money request actions functions (like updateDistanceRequest, updateMoneyRequestMerchant, updateMoneyRequestCategory, updateMoneyRequestTag...) use the getUpdateMoneyRequestParams function.

Could you please add a sample code that describes which changes should we make in getUpdateMoneyRequestParams function?

[dominictb]

Will provide an update early tomorrow.

[rayane-djouah]

TY!

[slafortune]

Adding another BZ - I'll be out until 8/21

[melvin-bot]

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

[dominictb]

#46914 (comment) proposal updated!

[rayane-djouah]

@dominictb's proposal looks good to me

🎀👀🎀 C+ reviewed

[melvin-bot]

Current assignee @dangrous is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[melvin-bot]

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

[dangrous]

Yep, looks good to me! I'm wondering - to solve the "There's no violation before, but after edit there's violation" case, could we just do: currentTransactionViolations.length != nextViolationOnyxUpdate.value.length?

[melvin-bot]

📣 @rayane-djouah 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

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

[dylanexpensify]

Nice, @dominictb when can we get the PR raised for review?

[dominictb]

The PR will be ready by tmr.

[dangrous]

Okay so in talking with @mountiny and trying to make this work on the backend, it's going to bog down our code speed and also just be very tricky to do it currently. However! We're in the process of migrating the next steps code, and once that's done we should be able to fix this much more easily.

It does mean in the meantime, though, that we won't want to merge this front-end fix if it will just be overwritten by the backend. So I think this (and the PR, which I'll post on too) will be on hold for the next steps migration to auth. Sorry for the trouble!

[melvin-bot]

This issue has not been updated in over 15 days. @dangrous, @slafortune, @rayane-djouah, @dominictb eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[dangrous]

Still on hold Melvin, don't close this.

[rayane-djouah]

Hold on #42118

[dangrous]

We've actually got a temporary backend fix that should get this moving again, should be merged soon. We're still doing the migration, but I'm pretty sure this will work in the meantime.

[rayane-djouah]

Great! Please let us know once it's deployed

[dangrous]

Okay I thinkkkkk this is deployed. Can we retest and see if it's fixed?