mWeb - After sending an invoice to a new user, it gets changed to some other user after a few minutes

[kbecciv]

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.73.1
Reproducible in staging?: y
Reproducible in production?: n
Issue reported by: Applause - Internal Team

Action Performed:

Pre-condition: Login with gmail account

1. Go to https://staging.new.expensify.com/home
2. Tap fab -- send invoice
3. Enter an amount and tap continue
4. Select a new user
5. Tap send invoice
6. Wait for few seconds, when header changes to hidden, tap on invited contact
7. Tap message user
8. Note email not found error
9. Navigate back to send invoice page and pin it
10. Navigate to LHN and open the report after few seconds
11. Open the report and wait few seconds

Expected Result:

After sending an invoice to a new user, it doesn't get changed to some other user after a few minutes

Actual Result:

After sending an invoice to a new user, it gets changed to some other user after a few minutes

Workaround:

n/a

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

Add any screenshot/video evidence

Bug6479798_1715629082333.Screenrecorder-2024-05-14-00-53-45-8_compress_1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

1. If you find which PR caused the issue/bug, you can reassign it to the person responsible for it.
   • If the author is OOO or won’t get online before the daily deploy is due, you are responsible for finding the best fix/path forward. Don’t hesitate to ask for help!
2. Try to reproduce the issue, if the bug is on production, remove the DeployBlocker label but stay assigned to fix it (or find out which PR broke it to get help from the author).
   • You can adjust the urgency of the issue to better represent the gravity of the bug.
   • If the issue is super low priority, feel free to un-assign yourself.
   • Be careful with PHP warnings, sometimes it is more complex than just adding a null coalescing operator as they might be uncovering some bigger bug.
   • If it was a one-off issue that requires no action (for example, Bedrock was down or it is a duplicated issue), you can close it.

Remember rule #2: Never un-assign yourself from a real DeployBlocker unless you are 100% sure someone else is assigned and will take care of it.

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

[kbecciv]

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

[yuwenmemon]

I can't reproduce this and the other errors that are described in the pre-requisite steps are reproducible in prod:

Removing the label

[yuwenmemon]

@cristipaval Do you know about the error here?

[melvin-bot]

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

[yuwenmemon]

@cristipaval quick bump on the above!

[cristipaval]

Sorry I missed the initial tag. I think this got fixed by this PR.

[yuwenmemon]

Sweeeeet! No worries at all. Closing this out!