[Due for payment 2025-09-19] [$250] Split offline - Only one individual chat shown offline, online there is a 3 avatars appear

[lanitochka17]

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.1.84-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2148171/folder/12015350/test-cases/39318429
Issue reported by: Applause - Internal Team

Action Performed:

1. Sign in to ND with a gmail account, created with "Track and budget" onboarding option
2. Enable "Force offline" mode
3. Click green "+" button (FAB), select "Start chat"
4. Create a group with two other gmail users, with whom you did not interact yet
5. In the group chat split a manual expense
6. Observe the LHN - only one individual chat is created
7. Go online, open each individual chat created after splitting an expense

Expected Result:

Two individual chats are created when splitting an expense in a group with two other participants. Each individual chat shows the other user's avatar in the conversation and in the LHN

Actual Result:

Only one individual chat appear in the LHN when splitting an expense in a group with two other participants offline. After going online, each individual chat shows the 3 avatars (one is fallback) in the conversation and in the LHN

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6895628_1753211561335.Recording__800.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021948104033241696448
• Upwork Job ID: 1948104033241696448
• Last Price Increase: 2025-07-23

Issue Owner

Current Issue Owner: @alexpensify

[melvin-bot]

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

[bernhardoj]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Only 1 chat is shown when creating a split while offline and after going online, the DM chat shows 3 avatars.

What is the root cause of that problem?

For the only 1 chat shows problem, it's the onyx problem where it doesn't send all the reportUpdates. This is currently an issue that happening on other places too (and there is issue that handling it), so I don't focus that here.

App/src/hooks/useSidebarOrderedReports.tsx

Line 59 in 15aa1ad

const [chatReports, {sourceValue: reportUpdates}] = useOnyx(ONYXKEYS.COLLECTION.REPORT, {canBeMissing: true});

For the other issue, after we go online, the DM chat has 3 participants. 1 participant is optimistic participant that should be removed. But why isn't it removed?

We already have a logic to remove the optimistic participant when success creating the split.

App/src/libs/actions/IOU.ts

Lines 1679 to 1689 in 15aa1ad

	if (isNewChatReport) {
	successData.push(
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${chat.report?.reportID}`,
	value: {
	participants: redundantParticipants,
	pendingFields: null,
	errorFields: null,
	},
	},

redundantParticipants contains the list of optimistic participants from personalDetailListAction.

App/src/libs/actions/IOU.ts

Lines 1648 to 1657 in 15aa1ad

	const redundantParticipants: Record<number, null> = {};
	if (!isEmptyObject(personalDetailListAction)) {
	const successPersonalDetailListAction: Record<number, null> = {};
	// BE will send different participants. We clear the optimistic ones to avoid duplicated entries
	Object.keys(personalDetailListAction).forEach((accountIDKey) => {
	const accountID = Number(accountIDKey);
	successPersonalDetailListAction[accountID] = null;
	redundantParticipants[accountID] = null;
	});

However, oneOnOnePersonalDetailListAction only contains the value if a new optimistic personal detail will be created when doing the split.

App/src/libs/actions/IOU.ts

Lines 6425 to 6436 in 15aa1ad

	const oneOnOnePersonalDetailListAction: OnyxTypes.PersonalDetailsList = shouldCreateOptimisticPersonalDetails
	? {
	[accountID]: {
	accountID,
	// Disabling this line since participant.displayName can be an empty string
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	displayName: formatPhoneNumber(participant.displayName || email),
	login: participant.login,
	isOptimisticPersonalDetail: true,
	},
	}
	: {};

But in our case, we are not creating a new personal detail, but rather using the existing optimistic personal detail. So, even it's not a new personal detail, it's still an optimsitic one.

What changes do you think we should make in order to solve the problem?

We have 2 options. First, the simplest one, we can update shouldCreateOptimisticPersonalDetails to also check whether the personal detail is optimistic or not.

App/src/libs/actions/IOU.ts

Lines 6345 to 6352 in 15aa1ad

	if ((!hasMultipleParticipants && !existingSplitChatReportID) || isOwnPolicyExpenseChat || isOneOnOneChat(splitChatReport)) {
	oneOnOneChatReport = splitChatReport;
	shouldCreateOptimisticPersonalDetails = !existingSplitChatReport && !personalDetailExists;
	} else {
	const existingChatReport = getChatByParticipants([accountID, currentUserAccountID]);
	isNewOneOnOneChatReport = !existingChatReport;
	shouldCreateOptimisticPersonalDetails = isNewOneOnOneChatReport && !personalDetailExists;
	oneOnOneChatReport =

(...) || !!allPersonalDetails[accountID]?.isOptimisticPersonalDetail

OR

We can have a new param similar to personalDetailListAction that we pass to buildOnyxDataForMoneyRequest, but instead of containing the list of new optimistic personal detail, it contains the list of existing optimistic personal detail. Then, add it to the redundantParticipants like this.

App/src/libs/actions/IOU.ts

Lines 1648 to 1657 in 15aa1ad

	const redundantParticipants: Record<number, null> = {};
	if (!isEmptyObject(personalDetailListAction)) {
	const successPersonalDetailListAction: Record<number, null> = {};
	// BE will send different participants. We clear the optimistic ones to avoid duplicated entries
	Object.keys(personalDetailListAction).forEach((accountIDKey) => {
	const accountID = Number(accountIDKey);
	successPersonalDetailListAction[accountID] = null;
	redundantParticipants[accountID] = null;
	});

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can test creating a group chat first (but pause the fetch mock so the success data isn't applied yet), then split bill in the group chat and verify each DM chat only has 2 participants.

[mkzie2]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Only one individual chat appear in the LHN when splitting an expense in a group with two other participants offline. After going online, each individual chat shows the 3 avatars (one is fallback) in the conversation and in the LHN

What is the root cause of that problem?

The problem is that the optimistic participant is not removed after we create a split expense, and participants is an object. Then, after the API is complete, the current participant is also merged into participants, which causes the DM chat to become a group.

The optimistic participant is not removed because shouldCreateOptimisticPersonalDetails is false here. It's only true if the personal details doesn't exist. In our case, after creating the group chat, the personal detail exists, and it's an optimistic personal detail

App/src/libs/actions/IOU.ts

Line 6351 in 15aa1ad

shouldCreateOptimisticPersonalDetails = isNewOneOnOneChatReport && !personalDetailExists;

App/src/libs/actions/IOU.ts

Lines 6425 to 6436 in 15aa1ad

	const oneOnOnePersonalDetailListAction: OnyxTypes.PersonalDetailsList = shouldCreateOptimisticPersonalDetails
	? {
	[accountID]: {
	accountID,
	// Disabling this line since participant.displayName can be an empty string
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	displayName: formatPhoneNumber(participant.displayName || email),
	login: participant.login,
	isOptimisticPersonalDetail: true,
	},
	}
	: {};

So the redundantParticipants doesn't contain the optimistic personal detail here.

App/src/libs/actions/IOU.ts

Lines 1648 to 1657 in 15aa1ad

	const redundantParticipants: Record<number, null> = {};
	if (!isEmptyObject(personalDetailListAction)) {
	const successPersonalDetailListAction: Record<number, null> = {};
	// BE will send different participants. We clear the optimistic ones to avoid duplicated entries
	Object.keys(personalDetailListAction).forEach((accountIDKey) => {
	const accountID = Number(accountIDKey);
	successPersonalDetailListAction[accountID] = null;
	redundantParticipants[accountID] = null;
	});

What changes do you think we should make in order to solve the problem?

1. If the personal detail is optimistic personal detail and shouldCreateOptimisticPersonalDetails is false, we can update oneOnOnePersonalDetailListAction to the optimistic personal detail, then this accountID can be removed in the success data. or we can update shouldCreateOptimisticPersonalDetails condition to return true if the personal detail is optimistic personal detail.

if (isOptimisticPersonalDetail(accountID) && !shouldCreateOptimisticPersonalDetails) {
    oneOnOnePersonalDetailListAction[accountID] = allPersonalDetails[accountID];
}

App/src/libs/actions/IOU.ts

Line 6425 in 15aa1ad

const oneOnOnePersonalDetailListAction: OnyxTypes.PersonalDetailsList = shouldCreateOptimisticPersonalDetails

2. The bug also happens if we start chat with any optimistic members in the group chat after creating the group with the same RCA, and we also need to fix this

if (!isOptimisticAccount) {
    if (isOptimisticPersonalDetail(accountID)) {
        settledPersonalDetails[accountID] = null;
        // BE will send different participants. We clear the optimistic ones to avoid duplicated entries
        redundantParticipants[accountID] = null;
    }
    return;
}

App/src/libs/actions/Report.ts

Lines 1208 to 1230 in 15aa1ad

	participantLoginList.forEach((login, index) => {
	const accountID = participantAccountIDs.at(index) ?? -1;
	const isOptimisticAccount = !allPersonalDetails?.[accountID];
	if (!isOptimisticAccount) {
	return;
	}
	optimisticPersonalDetails[accountID] = {
	login,
	accountID,
	displayName: login,
	isOptimisticPersonalDetail: true,
	};
	settledPersonalDetails[accountID] = null;
	// BE will send different participants. We clear the optimistic ones to avoid duplicated entries
	redundantParticipants[accountID] = null;
	});
	successData.push(
	{
	onyxMethod: Onyx.METHOD.MERGE,

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can create a test with the flow Create group chat --> Split bill with the initial status as offline. Then we can mock the response and verify that the new individual chat has only 2 participants.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021948104033241696448

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @eVoloshchak (External)

[alexpensify]

@eVoloshchak - can you please review if one of these proposals will fix the issue? Thanks!

[melvin-bot]

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