Expense - Duplicate transaction threads with RBR in LHN when sending expense to each other

[izarutskaya]

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.80-9
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4601025
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

Precondition:

• User A and B have no chatted before.
• Both accounts must be new.

1. Go to staging.new.expensify.com
2. [User A] Go offline.
3. [User A] Submit an expense to User B.
4. [User B] Submit an expense with the same amount to User A.
5. [User A] Go online.

Expected Result:

User A will not have two same transaction threads with RBR on LHN.

Actual Result:

User A receives two same transaction threads with RBR on LHN (not the main chat).

Workaround:

Unknown

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

Bug6504507_1717721951733.20240607_085343.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @lschurr (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.

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

[izarutskaya]

@lschurr 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.

[izarutskaya]

We think this issue might be related to the #collect project.

[izarutskaya]

Production

Recording.2511.mp4

[luacmartins]

Seems like it could be caused by #41507

[luacmartins]

I can confirm that reverting #41507 fixes the issue. I'm gonna go ahead with the revert since that PR also caused other regressions.

[luacmartins]

Got a revert PR up

[roryabraham]

fixed by a revert, no payments due