[$250] Workspace - Approve button returns briefly for the admin after approving the expense

[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.83-1 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/4627303&group_by=cases:section_id&group_id=306206&group_order=asc Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: applause internal team Slack conversation:

Action Performed:

Precondition: Create a Collect workspace in ND with an expensifail account. Invite a Gmail account as a member. Enable Workflows and add a Plaid Regions bank account.

1. Member: Navigate to https://staging.new.expensify.com/

2. Member: Log in

3. Admin: Log in

4. Member: Submit a manual expense to the workspace chat

5. Admin: Quickly open the IOU and approve it

Expected Result:

"Pay with Expensify" should be there until the expense is paid.

Actual Result:

"Pay with Expensify" button appears after approving, after a few seconds, it reverts to "Approve" and back to "Pay with Expensify".

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

https://github.com/Expensify/App/assets/43996225/8f7906fb-c568-419d-9c6a-99300e943b83

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01ee0bafa7bb3dc0e3
• Upwork Job ID: 1802955877876368442
• Last Price Increase: 2024-10-22
• Automatic offers:
• ZhenjaHorbach | Reviewer | 102863571

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @techievivek

[melvin-bot[bot]]

Triggered auto assignment to @stephanieelliott (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]

@stephanieelliott 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]

We think this bug might be related to #wave-collect - Release 1

[melvin-bot[bot]]

@stephanieelliott Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[stephanieelliott]

Waiting for proposals on this one

[VickyStash]

Hi, I'm Viktoryia from Callstack - expert contributor group - and I would like to work on this issue.

[VickyStash]

I wasn't able to reproduce the issue. Approve button doesn't return for me.

https://github.com/Expensify/App/assets/23176449/f50f7001-37a4-4f17-a929-10ee02586fe3

[melvin-bot[bot]]

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

[ZhenjaHorbach]

Not overdue I will try to reproduce this issue tomorrow

[VickyStash]

Note: I'll be OOO on Monday (24.06) 🌴

[ZhenjaHorbach]

I confirm that the bug is reproducible Out of 7 attempts, 3 times were successful

https://github.com/Expensify/App/assets/68128028/d1b31c05-b78b-49ed-94a5-bcc33ab9398a

[melvin-bot[bot]]

📣 @ZhenjaHorbach 🎉 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

[stephanieelliott]

Thanks @ZhenjaHorbach! @VickyStash sounds like this is intermittent, maybe try reproing a few times?

[VickyStash]

I haven't had a lot of time today for this issue, but I was finally able to reproduce the issue.

It looks like the issue can be caused by a combination of OpenReport and ApproveMoneyRequest API calls. So if a user quickly opens the expense quickly and press the Approve button, the following steps can happen:

1. The OpenReport API command is called when the expense is opened. In cases when I was able to reproduce this issue this request took 2+ seconds.
2. During OpenReport is processed, user taps on Approve button => local DB got updated with optimistic data for expense Approval. As a result the user see the Approve button turns into Pay.
3. The app gets the response of OpenReport API call, and the onyx data got updated with the data without approval information since API didn't know about the approval. As a result the user see the Pay button turns into Approve.
4. In the background ApproveMoneyRequest API call takes around 10-15 seconds. After that time the app gets the response of the Approval request and the onyx data got updated again with the correct data. As a result the user see the Approve button turns into Pay again.

I need some time to think about the solution.

[VickyStash]

Unfortunately, I haven't had enough time today to investigate this issue more, I'll do my best to take a look tomorrow.

[stephanieelliott]

Thanks @VickyStash! Glad we were at least able to nail down how to repro it

[VickyStash]

Note: I'll be OOO Jul 1 - Jul 7 🌴

[melvin-bot[bot]]

@VickyStash @stephanieelliott @ZhenjaHorbach this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot[bot]]

@VickyStash, @stephanieelliott, @ZhenjaHorbach Whoops! This issue is 2 days overdue. Let's get this updated quick!

[stephanieelliott]

@VickyStash is working on this. Given that it's hard to repro and is mostly a display issue that does not impact app functionality, we'll hold on this while they are OOO next week. Setting this to Weekly in the meantime since there will likely be no updates for several days.

[pasyukevich]

Hi, I'm Eugene from Callstack - expert contributor group.

I have the capacity and am going to take over the issue

[stephanieelliott]

Great, thanks @pasyukevich -- I've assigned you on this issue!

[melvin-bot[bot]]

Triggered auto assignment to @sonialiap (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details. Please add this Feature request to a GH project, as outlined in the SO.

[stephanieelliott]

Applying the New Feature label to get another BZ member on this while I am OOO til July 10. To catch you up on where we are @sonialiap, expert contributor @pasyukevich just took over this issue and is looking into it..

Thanks for watching over this, I'll grab it back from you when I return!

[pasyukevich]

I was able to reproduce this behavior and am currently thinking about the solution

[pasyukevich]

Today's update: Still working on possible solutions for this problem

[pasyukevich]

Today's update:

As already mentioned, we have this issue only in the case of a delayed OpenReport Request during the opening of the expense page.

How this can be fixed: 


1. Improve response speed on the API side for OpenReport API request
2. Remove optimistic data on the Approve request and add the loading state to the button (change to blocking behavior)

Also as I see we have flow with lastUpdateID to track orders of updates for Onyx. But this part does not apply to the optimistic data race condition with API update.

I think that this issue is also connected with this one - https://github.com/Expensify/App/issues/37560.

This issue looks global and can be reproducible in other places.

Should I prepare a proposal with a fix only for this case or focus on a global one?

[ZhenjaHorbach]

This issue looks global and can be reproducible in other places.

Should I prepare a proposal with a fix only for this case or focus on a global one?

@stephanieelliott Hello 😃 What do you think about this comment from @pasyukevich ?

[stephanieelliott]

Yeah @pasyukevich, if that is possible then I think we may as well go for a global fix rather than just fixing this case.

[melvin-bot[bot]]

@pasyukevich @stephanieelliott @ZhenjaHorbach this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot[bot]]

@pasyukevich, @stephanieelliott, @ZhenjaHorbach Huh... This is 4 days overdue. Who can take care of this?

[pasyukevich]

Got it, I will switch back to this issue tomorrow

[stephanieelliott]

Thanks @pasyukevich!

[pasyukevich]

Work in progress - checking different scenarios to fix it globally

[melvin-bot[bot]]

@pasyukevich, @stephanieelliott, @ZhenjaHorbach 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[ZhenjaHorbach]

Not overdue Work in progress !

[pasyukevich]

Today's update:

Work in progress, preparing the proposal

[melvin-bot[bot]]

@pasyukevich, @stephanieelliott, @ZhenjaHorbach Whoops! This issue is 2 days overdue. Let's get this updated quick!

[ZhenjaHorbach]

Not overdue

[pasyukevich]

Proposal

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

When we open the freshly submitted expense from the collect workspace and press the "Approve" button quickly, we can see that the state of this button will change to "Pay", "Approve" and "Pay" back.

What is the root cause of that problem?

When we receive a Response from the "Approve" request straight after the OpenReport response we do not apply it and pause the queue as we detect inside the SaveResponseInOnyx that the previousUpdateID from the response is greater than lastUpdateIDFromClient. Because of this we are put on hold update and waiting additionaly for the getMissingOnyxUpdates request. In the middle of it, we are applying a response from the OpenReportRequest received just a moment before the ApproveMoneyRequest response. Only after the getMissingOnyxUpdates request is resolved, we apply the data from the ApproveMoneyRequest response.

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

On the API side, we need to have previousUpdateID inside the OpenReport request. In this case, we will detect the gap between the server and frontend state before showing the "Approve" button. User will be able to send ApproveMoneyRequestrequest only if the gap is eliminated

What alternative solutions did you explore? (Optional)

Change SaveResponseInOnyx method and even if we detected the gap between FE state and BE state apply a response for the current request, then put the queue on hold, and run getMissingOnyxUpdates request.

[ZhenjaHorbach]

@pasyukevich Thanks for your proposals I like both proposals But the second one looks more comprehensive And could potentially fix other bugs related to the request queue

But first, let's find out what the internal team thinks 🎀👀🎀 C+ reviewed

[melvin-bot[bot]]

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

[pasyukevich]

@stephanieelliott Can we have a review of the proposal from the internal team as @ZhenjaHorbach mentioned?

One of the proposals relates to the API side

[stephanieelliott]

Sure! @techievivek would you mind reviewing this proposal: https://github.com/Expensify/App/issues/43783#issuecomment-2252404214

[melvin-bot[bot]]

@pasyukevich, @stephanieelliott, @techievivek, @ZhenjaHorbach Whoops! This issue is 2 days overdue. Let's get this updated quick!

[ZhenjaHorbach]

Not overdue

[techievivek]

This one certainly is a tricky one, reviewing the GH to see how we can move forward here, thanks.

[ZhenjaHorbach]

Not overdue