[HOLD for payment 2024-12-03] [Search v1.2] Android - Expense - Unexpected error when submitting expense to same WS after paying another

[IuliiaHerets]

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.60-0
Reproducible in staging?: Y
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: 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/5204723&group_by=cases:section_id&group_order=asc&group_id=319502
Issue reported by: Applause Internal Team

Action Performed:

1. Open the Expensify app.
2. Tap on the FAB and select "Submit Expense"
3. Complete the expense creation process and send the expense to any workspace.
4. Tap on "Search" on the bottom of the screen.
5. Tap on "Outstanding"
6. Tap on "Pay" on the preview of the just created expense.
7. Tap on the FAB and select "Submit Expense"
8. Complete the expense creation flow and send the expense to the same workspace of the just paid expense.
9. Tap on "All"
10. Open the report of the two workspace expenses.
11. Verify the new expense was created properly and is displayed on search section.

Expected Result:

The user should be able to create a new expense and send it to the same workspace of the just paid one, and this new expense should be displayed properly on "Search" section.

Actual Result:

When the user pay an expense via "Pay" button on expense preview on search, create another one and send it to the same workspace, an "Unexpected error" is displayed and the new expense is not created.
Issue can be reproduced only with Gmail accounts.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6662199_1731396212678.Unexpected.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @luacmartins

Issue Owner

Current Issue Owner: @luacmartins

[melvin-bot]

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

Triggered auto assignment to @Beamanator (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[joekaufmanexpensify]

I can't reproduce this on my gmail.com account. Works fine for me. I see the issue title says Android, but multiple platforms are selected, so I tested on web.

2024-11-12_10-32-39.mp4

[joekaufmanexpensify]

@Beamanator are you able to reproduce?

[francoisl]

I can repro – it's worth noting that it only seems to happen with distance expenses. Going to check logs.

[francoisl]

https://www.expensify.com/_devportal/tools/logSearch/#query=request_id:(%228e18b520debecef5-SJC%22)+AND+timestamp:[2024-11-12T17:50:24.790Z+TO+2024-11-12T19:50:24.790Z]&index=logs_expensify-031172

403 New request cannot be added to this expense report - given the error, it's surprising that it would only happen on Android. I'll try to repro on web, it would be easier to troubleshoot.

[francoisl]

Looks like this is fixed on main, there's probably something that's been merged we just need to CP 👀
Actually maybe not, I was still able to repro on main. Super confused here.

[francoisl]

cc @luacmartins if you have any idea, since this is related to Search.

[francoisl]

Ok I think I finally figured out exactly why it's happening and why I couldn't repro consistently. I think it's a backend issue – when you pay an expense from the Search page, the command PayMoneyRequestOnSearch doesn't update the status of the IOU report in Onyx, so when you try to create another expense, the client tries to create it on the same report as the previous one because it thinks it's still open, but in the backend the report is actually reimbursed.

[luacmartins]

@francoisl I'm reverting my PR which allows paying expenses on Search. I can take over this issue to fix it in the v2 of my PR if you'd like

[luacmartins]

x, so when you try to create another expense, the client tries to create it on the same report as the previous one because it thinks it's still open

AFAIK the backend should handle this and just update the client.

[francoisl]

Ok yeah, works for me if you don't mind. Thanks!

[francoisl]

AFAIK the backend should handle this and just update the client.

Yeah that's what I was starting to look into - Auth only generates a snapshot_ update in this case (ref) - not super familiar with that feature so I wasn't sure if it's on purpose.

[Beamanator]

Thaaaaaaanks for getting this figured out gents 🙏

[luacmartins]

@joekaufmanexpensify I'm just keeping this open so I can track it in v2 of my PR that got reverted. I'll unassign you since we'll track that in the main issue.

[joekaufmanexpensify]

Got it. TY!

[melvin-bot]

@luacmartins Eep! 4 days overdue now. Issues have feelings too...

[luacmartins]

I put up a fix for this and we'll retest once the App PR is merged

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.66-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Show search action buttons v2 #52441

If no regressions arise, payment will be issued on 2024-12-03. 🎊

[melvin-bot]

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

[luacmartins]

This is done