[HOLD for payment 2025-01-13] [$250] Another invoice can't be sent after one is paid #53019
Comments
|
Triggered auto assignment to @zanyrenney ( |
|
@zanyrenney Whoops! This issue is 2 days overdue. Let's get this updated quick! |
|
triaged the bug. |
|
Job added to Upwork: https://www.upwork.com/jobs/~021861805315178904377 |
|
Triggered auto assignment to Contributor-plus team member for initial proposal review - @allgandalf ( |
|
Waiting for proposals |
|
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸 |
|
Not sure if this is purely FE, @neil-marcellini can you provide any more data from the logs, can you provide the data received in the logs to see if we send everything correctly ? |
|
Yeah fair, this is probably internal, at least to identify the root cause. |
|
@neil-marcellini @zanyrenney @allgandalf this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks! |
|
@neil-marcellini any updates here ? can you share some logs from devportal ? |
|
It looks like the problem is that we try to create the invoice room report again vs re-using the one that already exists. The invoiceRoomReportID is Logs
After some digging around I've found that we fail to get the I also noticed that in App that the invoiceReceiver value still has the accountID set within it, but the type is updated to policy. I think maybe the Onyx update doesn't clear the accountID properly, though maybe that's not a big deal. In Auth we should not be trying the get the invoice room with the receiver type sent to individual when it's been changed to policy, so is App passing the wrong parameters? I see that it's passing the If the So it looks like the next step is to figure out why the invoiceChatReport.reportID is not set in App. I don't like that App has so much control over whether this succeeds in Auth, but I'm not sure there is a way to fix that given the design. In this flow the user sends the second invoice to the individual (userB) via global create, and it's created as an invoice sent on the chat between userA's workspace and userB's, because userB chose to pay the invoice as a business the first time. That's actually kind of an odd UX, because once userB pays an invoice from you as a business you can't send them an invoice individually. I don't think we should force that. Maybe it's ok if userB can choose to pay it as an individual later, but I'm not sure due to this bug. Given all that, I will fix it in App for now, then start a discussion about whether we want to change the UX. |
|
The App PR with the fix is ready to go, I just need to write the manual test and record a video. |
|
@neil-marcellini kudos with the RCA investigation, I was 😮 reading traces and logs and your explanation !! (Wish i had access to auth repo to look more 😬 ) |
|
PR is ready for review! |
|
🔴 Hopeful to get the PR merged this week |
|
♻️ PR was merged!! |
|
🔴 PR yet to hit staging |
|
|
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.80-6 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 2025-01-13. 🎊 For reference, here are some details about the assignees on this issue:
|
|
@allgandalf @zanyrenney @allgandalf The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button] |
BugZero Checklist:
Bug classificationSource of bug:
Where bug was reported:
Who reported the bug:
Regression Test ProposalPrecondition:Test:
Do we agree 👍 or 👎 |
Payment Summary
BugZero Checklist (@zanyrenney)
|
|
@allgandalf invited you to the job! |
|
Accepted thanks!! |
|
can you double-check @allgandalf - it doesn't look like you have in upwork. Thanks! normally here we see "view hires" here if the offer has been accepted
|
|
payment summary paid $250 to @allgandalf via upwork. |
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.66-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
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: @neil-marcellini
Slack conversation (hyperlinked to channel name): Expensify billpay
Action Performed:
Expected Result:
The invoice report can be opened
Actual Result:
The invoice report is not found, because it failed to actually be created even though there was no error message shown in product. The Network response shows 400 Unique Constraints Violation
Backlogs : https://www.expensify.com/_devportal/tools/logSearch/#query=request_id:(%228e6c7cac282da4d0-MIA%22)+AND+timestamp:[2024-11-22T21:51:56.285Z+TO+2024-11-22T23:51:56.285Z]&index=logs_expensify-031332
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Add any screenshot/video evidence
Recording.787.mp4
MultipeInvoicesFail2024-11-22_17-52-27.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @zanyrenneyThe text was updated successfully, but these errors were encountered: