Split bill - Duplicated error message when making to split bill request with a user

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: v1.4.45-0
Reproducible in staging?: Y
Reproducible in production?: N
Email or phone of affected tester (no customers): natnael.expensify+3@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team

Action Performed:

Make a split bill request with a new user
Make another split bill request the user again

Expected Result:

'There is a previously existing chat between these users' error message shouldn't be duplicated

Actual Result:

'There is a previously existing chat between these users' error message is duplicated

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

Screenshots/Videos

Bug6396806_1709202810196.Screen_Recording_2024-02-29_at_10.42.37_in_the_morning.mp4

View all open jobs on GitHub

@adelekennedy

Triggered auto assignment to @adelekennedy (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

👋 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:

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

@Gonals

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

@Gonals

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

Taking a look after lunch!

@izarutskaya

@izarutskaya, why is the error expected in the first place? I don't think asking for a second split should cause an error at all

Yeah, looks like the app tries to generate a new chat, but I can't reproduce it.

Screen.Recording.2024-02-29.at.22.38.58.mov

One weird thing from the OP video though, is where the contacts list comes from

Yeah, looks like the app tries to generate a new chat, but I can't reproduce it.

Screen.Recording.2024-02-29.at.22.38.58.mov
One weird thing from the OP video though, is where the contacts list comes from

It only happens if the chosen contact doesn't have an expensify account when you request the first split

I split with the identical user as the OP video and looks like it's an existing user as it has a display name of B. I also tried with random non-existing user but still can't reproduce.

I split with the identical user as the OP video and looks like it's an existing user as it has a display name of B. I also tried with random non-existing user but still can't reproduce.

On Staging? I can reproduce fine

Ok.
Seems like the errors is caused by how we generate the AccountID for the user when the user doesn't have an expensify account:

We generate an optimistic account in the front end and create the split.
We call the backend. The account gets created with a different accountID
We create a new split. The frontend fails to find the existing report because the participant's ID doesn't match.

Fix: Make sure we are passing correctly the optimistic accountID to the backend, and that the backend is actually using it to create the account.

Oh, I tested it on main. I can reproduce it on staging. After merging with the latest main, I can reproduce it (with a Hidden username).

Looks like the problem is in the report data itself.

The visibleChatMemberAccountIDs contains the wrong data. When creating the option, the accountID is taken from visibleChatMemberAccountIDs.

App/src/libs/OptionsListUtils.ts

Line 1463 in 807ce54

const accountIDs = report.visibleChatMemberAccountIDs ?? [];

FYI, this is likely fixed by this revert. Will have QA re-test once it is CP'd.

Looks like that revert ^ didn't fix the issue. So we still need to figure out what is going on here.

Reverting that PR locally does not fix the issue for me. I also reproduce this in production:

I think this is known and related to this issue: #30140

Also, I think in production we still don't have a way to split with a single user, so this looks like a deploy blocker because we just made it possible in the linked PR. But this issue is known and can be reproduced if you split with multiple users in production. I'll work on it soon.

Closing in favor of #30140

Navigation Menu

Repository navigation

Split bill - Duplicated error message when making to split bill request with a user #37492

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Split bill - Duplicated error message when making to split bill request with a user #37492

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Feb 29, 2024

github-actions commented on Feb 29, 2024

melvin-bot commented on Feb 29, 2024

izarutskaya commented on Feb 29, 2024

Gonals commented on Feb 29, 2024

Gonals commented on Feb 29, 2024

bernhardoj commented on Feb 29, 2024

Gonals commented on Feb 29, 2024

bernhardoj commented on Feb 29, 2024

Gonals commented on Feb 29, 2024

Gonals commented on Feb 29, 2024

bernhardoj commented on Feb 29, 2024

puneetlath commented on Feb 29, 2024

puneetlath commented on Feb 29, 2024

youssef-lr commented on Feb 29, 2024

youssef-lr commented on Feb 29, 2024

youssef-lr commented on Feb 29, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions