Closed kavimuru closed 1 week ago
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
I'm thinking of closing this dupe in favour of this issue as we've progressed further here. That said, can we confirm this will solve for the Submit
button on delayed submission, referenced here. I can't see why not, seems to be the same bug.
@techievivek please also review the proposal so we can move it on. ;)
@danieldoglas @chrispader (I believe Chris worked on part of this) would you be able to check out the proposal too, I am not 100% sure if this is safe to do
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.
I do not know any specific problem with this but just think there is a reason why its built the way its now
@techievivek please also review https://github.com/Expensify/App/issues/43783#issuecomment-2252404214 so we can move it on. ;)
I looked through the proposal, but both solutions need verification from experts. Vit has already tagged Daniel, so I will wait for them to review it and share their thoughts.
Also ccing @iwiznia and @tgolen since this change is related to Onyx updates. Thanks.
@techievivek I think we need to investigate the method that is being called for approving the report. It's probably not returning all the onyxUpdates it should, which then generates the gap for the next request.
I don't have any immediate thoughts, but I am intently following along!
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.
I do not know any specific problem with this but just think there is a reason why its built the way its now
The reason this was done is so that everything happens to the client in the right order. If there is a gap of Onyx updates, that gap should be applied before the updates in the current response, or else the updates in the gap might overwrite the changes in the current response.
Tim is right and we should not change that behavior. It seems that in this flow we always go through the getMissingOnyxUpdates
flow? If so what we need to do is figure out why that happens, as that should be rare and only happen when you missed an onyx update.
Not overdue
@techievivek have you been able to investigate this suggestion?
@techievivek I think we need to investigate the method that is being called for approving the report. It's probably not returning all the onyxUpdates it should, which then generates the gap for the next request.
No, I haven't been able to triage this again, I will take a look into it by tomorrow at max.
I looked through the request, and it seems like some updates are missing in the response. As a result, we call GetMissingOnyxMessages
to fetch those updates.
Yeah that sounds wrong, can you debut it further to figure out why that happens?
@pasyukevich, @stephanieelliott, @techievivek, @ZhenjaHorbach Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@pasyukevich, @stephanieelliott, @techievivek, @ZhenjaHorbach 6 days overdue. This is scarier than being forced to listen to Vogon poetry!
Hey @techievivek have you had a chance to debug any further on this one?
No updates from last week. I will debug this further this week.
Thanks, that would be great because this is pretty janky in a mainline core flow. 👍
Just a note that this issue is linked to an external deadline of Sept 9th, if you can try and prioritize it soon @techievivek!
Hey, I have a few other similar priority issue on my plate, can we look for a volunteer here, thanks. 🙇
Ah, out of curiosity, which issues are those @techievivek? This is a long standing issue at this point in a core usage flow, I'd rather not go back to the drawing board with catching someone up with the history if priorities can align.
There is another wave-control issue on my plate where we are going back and forth with the reviews https://github.com/Expensify/Auth/pull/11996
Thanks!
I'm currently handling two Fast-API issues: https://github.com/Expensify/Expensify/issues/419963 and https://github.com/Expensify/Expensify/issues/408736.
Both of these are LOW
and HIGH
in #fast-apis, which is below CRITICAL
where this issue is classified in #wave-collect as we focus on bugs in core flows as the deliverable for the SuiteWorld release.
There is another wave-control issue on my plate where we are going back and forth with the reviews https://github.com/Expensify/Auth/pull/11996
That one looks like it's attached to the Violations in Auth project which is classified as HIGH in the OP tracker, and #wave-control list of projects in the channel here.
So I would suggest this issue takes priority 👍
sorry did not mean to touch the label here. readding!
Current assignee @ZhenjaHorbach is eligible for the External assigner, not assigning anyone new.
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
@techievivek just wondering if you had any thoughts on my comment here: https://github.com/Expensify/App/issues/43783#issuecomment-2340272990
@techievivek another bump on this -- the two Fast-API issues you referenced were closed yesterday, can we bump the priority of this one now?
Yes, it's now a top priority for me. Since I'm still getting familiar with the flow, it's taking a bit longer, I will update the GH today.
Hmm, I can't reproduce this anymore. I'm going to ask QA if it's still reproducible. P.S. Asked here https://expensify.slack.com/archives/C9YU7BX5M/p1726501151009569
@techievivek The app has changed a bit, now tester only have the pay button without additional setup, but tester can still repro the issue with the pay button.
https://github.com/user-attachments/assets/2cb0c404-acad-4250-b35b-8af967dcdeac
https://github.com/user-attachments/assets/2bc79186-1a2e-451d-b643-a12b34e969af
@kavimuru
The app has changed a bit, now tester only have the pay button without additional setup, but tester can still repro the issue with the pay button.
I think you will need to be on control policy and have the approval flow set so that when we submit an expense above a certain amount, admins need to manually approve it before paying.
@trjExpensify Are you able to reproduce this? I have been trying to reproduce this since yesterday but have had no luck. Am I holding anything wrong here?
https://github.com/user-attachments/assets/2fb4409a-2205-46f2-bab2-adee4f4c1189
CC @stephanieelliott can you also give it a look and see if you can reproduce it? Thanks.
@techievivek The app has changed a bit, now tester only have the pay button without additional setup, but tester can still repro the issue with the pay button.
QA repro'd 18 hours ago in that video? Let's confirm their setup.
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
@pasyukevich, @stephanieelliott, @techievivek, @ZhenjaHorbach Whoops! This issue is 2 days overdue. Let's get this updated quick!
@techievivek did you confirm the setup in Slack?
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
@pasyukevich, @stephanieelliott, @techievivek, @ZhenjaHorbach Still overdue 6 days?! Let's take care of this!
Hey @techievivek, what's the latest here?
I have been ooo for the last four working days. I'm catching up, but updating here that I haven't yet confirmed the setup used by QA on Slack.
Okay, well the first diff I see in your video here versus the prerequisite steps in the OP (copied below), and QA's video here, is that it doesn't look like you're testing with a VBBA connected to the workspace. I'd start there.
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.
I tested this again following Tom's comment above. While I couldn’t reproduce the original issue mentioned in the GH OP https://github.com/Expensify/App/issues/43783#issue-2353765649, I was able to replicate the problem Applause highlighted here: https://github.com/Expensify/App/issues/43783#issuecomment-2353526195. Specifically, I had to click 'Pay with Expensify' twice for the payment to go through, which is definitely a bug.
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
Great! It would be ideal to replicate the exact conditions to rule those out for the approve button flash - so don't have dupes to cause Hold
to be another variable in the mix, and per the OP, the invited member is a gmail account.
Either way, agree the Pay
button shouldn't need to be clicked twice. Also, did you keep an eye on the LHN, see how that preview messages goes from approved > paid > approved > paid?
https://github.com/user-attachments/assets/c2688fd7-ef95-480a-a592-6116f99743f5
@pasyukevich, @stephanieelliott, @techievivek, @ZhenjaHorbach Whoops! This issue is 2 days overdue. Let's get this updated quick!
I noticed an inconsistency while testing locally. It seems we are creating two MANUALREIMBURSED actions when trying to process the expense request, which is why it requires clicking the pay button twice. Something seems off in my DEV environment, so I'll continue investigating once I get newdot running again.
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
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.
Member: Navigate to https://staging.new.expensify.com/
Member: Log in
Admin: Log in
Member: Submit a manual expense to the workspace chat
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?
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
Issue Owner
Current Issue Owner: @Issue Owner
Current Issue Owner: @techievivek