[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

[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?

[rayane-djouah]

@slafortune Can we bump this to weekly? Thanks!

[dangrous]

Did we get QA to retest this?

[rayane-djouah]

@dangrous - The backend no longer returns the "Waiting for user to fix the issue(s)" next step, even when there is a violation.

Staging:

Screen.Recording.2024-11-06.at.1.22.17.PM.mov

PR branch:

Screen.Recording.2024-11-06.at.1.24.28.PM.mov

Could you please provide more details on the temporary backend fix that you implemented? Also, how should we handle the next step on the frontend after this change?

[dangrous]

hrm can you let me know how you set up the workspace / rules / etc. so I can try to replicate? I've found one place in the code that I can fix, but I think there's another one.

Also @mountiny did we figure out how to fix that issue with the cached violations? That's not this bug, but it's related.

[mountiny]

Also @mountiny did we figure out how to fix that issue with the cached violations? That's not this bug, but it's related.

I think yes, will send you a PR

[mountiny]

This is the PR btw https://github.com/Expensify/Web-Expensify/pull/44311 however, after testing it locally the cache seems to not get updated before the report next steps are computed. It will require more digging 🕳️

[dominictb]

hrm can you let me know how you set up the workspace / rules / etc. so I can try to replicate?

cc @rayane-djouah

@dangrous You can try steps 1 - 5 in this comment.

[dangrous]

Thanks @dominic! So we're looking at two next step issues (cc @mountiny).

For a policy on Instant Submit, we're hitting this block even if a report has violations. We should probably add a condition there, that's relatively easy, and doesn't change any existing tests.

For a policy on manual submit, we SHOULD be hitting this block, but we're not because the logic is checking a lot of stuff about that specific user, and it's conflicting for some reason. So instead we're going down here. I think we can probably just drop everything after $hasViolations since everything is more streamlined now? But I'm not 100% sure. The tests would need some adjustment but I'm hopelessly confused now as to what is "expected".

[rayane-djouah]

@mountiny kind bump on this

[mountiny]

@dangrous sounds right, but I agree this is really finicky and gotta be careful around the test

[dangrous]

So I think a lot of the tests are messed up, annoyingly. E.g they're creating reports with expenses that have violations, when that's not the behavior they're testing. See my latest comment on https://github.com/Expensify/Web-Expensify/pull/44527 . I'm trying to power through and make these changes correctly, but a little stuck

[dangrous]

eyyy we can comment again. Just posted on the PR with a potential fix so we can get this moving again. Still need to actually fix the next steps, but this would update the caching

[dangrous]

okay so the caching is fixed, the instant submit case is fixed, I just need to implement the manual submit case. And then we should be good? WIP is here https://github.com/Expensify/Web-Expensify/pull/44527

[dangrous]

okay I think I got all of it in that PR - will take it out from draft momentarily

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[dangrous]

Amazing! Where do we stand on this issue, all? Assuming we can't reproduce anymore, can we just close? Is payment needed? Further front end work? Thanks!

[dangrous]

this is on prod now, so bumping ^ - thanks!

[dominictb]

@dangrous I still don't see the Waiting for ABC to fix the issue(s) next step message when the expense has violation:

That's why QA cannot reproduce the issue. Is there something I'm missing? cc @rayane-djouah

[dangrous]

okay well we just reverted the PR haha so that's your issue here... I think we're back to the drawing board unfortunately. We'll be taking another look at the backend today. One day we'll get there.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[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!