[Due for payment 2026-01-30] [$250] Split - Split Expense creates extra hidden participant when non‑existing Admin is added

[vincdargento]

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: V9.2.95
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): lattelover1412+0801@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Win11/Chrome
App Component: Money Requests

Action Performed:

1. Open the link www.staging.new.expensify.com
2. User logged in
3. Create a new workspace
4. Navigate to Workspace >> Members >> Add non-existing account and set role as Admin
5. Go to Inbox >> Go to Admin >> Click on + >> Select "Split expense"
6. Select "Distance" >> enter start point and end point >> click "Next"

Expected Result:

Split expense should only divide between the 2 selected members. No hidden avatar should be created.

Actual Result:

on the confirm detail page, the split divided into 3 instead of 2, A third split is assigned to a hidden avatar. if the user go ahead with the split, an red dot and error will be displayed on the LHN.

Note:
Same issue occurs when selecting Manual and Scan options
Issue is reproducible only when the added member is a non‑existing Admin

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

bug2.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022011393489401037653
• Upwork Job ID: 2011393489401037653
• Last Price Increase: 2026-01-14

Issue Owner

Current Issue Owner: @heyjennahay

[melvin-bot]

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

[twinkle-react]

Proposal

---

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

When creating a split expense from a workspace chat, if a non-existing admin has been added to the workspace, the split confirmation shows 3 participants instead of 2, with a hidden avatar representing the extra participant. This results in a red dot and error on the LHN.

---

What is the root cause of that problem?

The getOrCreateOptimisticSplitChatReport function incorrectly reuses existing chat reports as split chats even when the split has multiple participants.

When a split is initiated from a workspace chat with multiple selected participants, the function reuses the existing workspace chat as the split chat instead of creating a new group chat. This causes the split logic to include the workspace as an additional participant, resulting in 3 splits instead of the expected 2.

---

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

Modify getOrCreateOptimisticSplitChatReport in
src/libs/actions/IOU/index.ts to only reuse existing chat reports when participants.length <= 1.

For splits with multiple participants, always create a new group chat to avoid including unintended participants from the existing chat.

// index.ts Lines 6484-6520
function getOrCreateOptimisticSplitChatReport(
    existingSplitChatReportID: string | undefined,
    participants: Participant[],
    participantAccountIDs: number[],
    currentUserAccountID: number,
) {
    // The existing chat report could be passed as reportID or exist on the sole "participant" (in this case a report option)
    const existingChatReportID = existingSplitChatReportID ?? participants.at(0)?.reportID;

    // Check if the report is available locally if we do have one
    const existingSplitChatOnyxData =
        allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${existingChatReportID}`];

    let existingSplitChatReport =
        existingChatReportID && existingSplitChatOnyxData
            ? { ...existingSplitChatOnyxData }
            : undefined;

    const allParticipantsAccountIDs = [
        ...participantAccountIDs,
        currentUserAccountID,
    ];

    if (!existingSplitChatReport) {
        existingSplitChatReport = getChatByParticipants(
            allParticipantsAccountIDs,
            undefined,
            participantAccountIDs.length > 1,
        );
    }

    // Only reuse existing chat reports for single-participant splits
    if (existingSplitChatReport && participants.length <= 1) {
        return {
            existingSplitChatReport,
            splitChatReport: existingSplitChatReport,
        };
    }

    // Create a group chat for multiple participants
    if (participants.length > 1) {
        const splitChatReport = buildOptimisticChatReport({
            participantList: allParticipantsAccountIDs,
            reportName: '',
            chatType: CONST.REPORT.CHAT_TYPE.GROUP,
            notificationPreference:
                CONST.REPORT.NOTIFICATION_PREFERENCE.ALWAYS,
        });

        return {
            existingSplitChatReport: null,
            splitChatReport,
        };
    }

    // Otherwise, create a new 1:1 chat report
    const splitChatReport = buildOptimisticChatReport({
        participantList: participantAccountIDs,
    });

    return {
        existingSplitChatReport: null,
        splitChatReport,
    };
}

---

What alternative solutions did you explore? (Optional)

• Filtering out invalid participants in the confirmation list
  Masks the symptom but does not fix the underlying issue of incorrect chat reuse.

[bernhardoj]

Proposal

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

Split expense shows Hidden participant after inviting new user to WS member.

What is the root cause of that problem?

When we add new members to WS, we optimistically add them to the admins room too (if their role is admin). But when success, we don't clear the optimistic user from the participants list.

App/src/libs/actions/Policy/Member.ts

Lines 163 to 169 in 99867a7

	roomMembers.successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${report?.reportID}`,
	value: {
	pendingChatMembers: reportMetadata?.pendingChatMembers ?? null,
	},
	});

This is fine if we invite an existing user because their accountID is not optimistic. So, when the request is success, BE return the real participant, and now we have the extra optimistic participant left, uncleared.

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

We need to clear the participant if it's an optimistic account.

onyxMethod: Onyx.METHOD.MERGE,
key: `${ONYXKEYS.COLLECTION.REPORT}${report?.reportID}`,
value: {
    participants: accountIDs.reduce((acc, curr) => {
        if (ReportUtils.isOptimisticPersonalDetail(curr)) {
            Object.assign(acc, {[curr]: null});
        }
        return acc;
    }, {}),
},

[lorretheboy]

Proposal

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

Split Expense creates extra hidden participant when non‑existing Admin is added

What is the root cause of that problem?

When adding a new admin member to a workspace, we optimistically add them to the admins room with an optimistic accountID (generated client-side). And backend returns the real participant with the real accountID --> On success, we were only clearing pendingChatMembers but NOT removing the optimistic participants from the participants list
Thus, both the optimistic participant (with optimistic accountID) and the real participant (with real accountID) remain in the room, creating duplicate entries

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

We can clear the optimistic participants in the successData

@@ -160,13 +160,25 @@ function buildRoomMembersOnyxData(
             },
         },
     );
-    roomMembers.successData.push({
-        onyxMethod: Onyx.METHOD.MERGE,
-        key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${report?.reportID}`,
-        value: {
-            pendingChatMembers: reportMetadata?.pendingChatMembers ?? null,
+    roomMembers.successData.push(
+        {
+            onyxMethod: Onyx.METHOD.MERGE,
+            key: `${ONYXKEYS.COLLECTION.REPORT}${report?.reportID}`,
+            value: {
+                participants: accountIDs.reduce((acc, curr) => {
+                    Object.assign(acc, {[curr]: null});
+                    return acc;
+                }, {}),
+            },
         },
-    });
+        {
+            onyxMethod: Onyx.METHOD.MERGE,
+            key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${report?.reportID}`,
+            value: {
+                pendingChatMembers: reportMetadata?.pendingChatMembers ?? null,
+            },
+        },
+    );
     return roomMembers;
 }
 /**

App/src/libs/actions/Policy/Member.ts

Line 107 in 7d1c0e2

function buildRoomMembersOnyxData(

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]

@heyjennahay Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

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