[$250] mWeb - room- Inviting a previously unknown user to room displays member count incorrectly

[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.0.13
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Tap on a room chat -- header -- invite
3. Enter an email you have not previously had contact with eg: jaihanumanblog+1111@gmail.com
   and invite to room
4. Tap back button
5. Note members count

Expected Result:

Inviting an user to room via secondary contact must display member count correctly

Actual Result:

Inviting an user to room via secondary contact must display member count correctly

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

Add any screenshot/video evidence

Bug6552594_1721908859939.uu122.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01b5145e9ee0c2aee8
• Upwork Job ID: 1818427399700311066
• Last Price Increase: 2024-07-30

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[melvin-bot]

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

[lanitochka17]

We think that this bug might be related to #vip-vsp

[lanitochka17]

@stephanieelliott FYI 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

[FitseTLT]

Proposal

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

room-Inviting a user who you have no contact before displays member count incorrectly

What is the root cause of that problem?

The issue is not caused by using the secondary contact to add a member to a room (as indicated in OP) but instead when a user adds a member who's personal detail doesn't exist in onyx a new optimistic personal detail is created then after a while the real personal detail representing the member comes from BE and the optimistic personal detail will be deleted but the accountID of the optimistic personal detail still exists in report.participants list so the members count will be wrong as we display the participants length here

App/src/pages/ReportDetailsPage.tsx

Lines 305 to 306 in b0f810d

	subtitle: activeChatMembers.length,
	isAnonymousAction: false,

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

We should filter particpants whose personal details doesn't exist just the same as what we did in RoomMemebersPage here

App/src/pages/RoomMembersPage.tsx

Lines 174 to 180 in b0f810d

	participants.forEach((accountID) => {
	const details = personalDetails[accountID];
	if (!details) {
	Log.hmmm(`[RoomMembersPage] no personal details found for room member with accountID: ${accountID}`);
	return;
	}

We should change

App/src/pages/ReportDetailsPage.tsx

Lines 138 to 141 in b0f810d

	const participants = useMemo(() => {
	const shouldExcludeHiddenParticipants = !isGroupChat && !isSystemChat;
	return ReportUtils.getParticipantsAccountIDsForDisplay(report, shouldExcludeHiddenParticipants);
	}, [report, isGroupChat, isSystemChat]);

to

const participants = useMemo(() => {
        const shouldExcludeHiddenParticipants = !isGroupChat && !isSystemChat;
        const participantAccountIDs = ReportUtils.getParticipantsAccountIDsForDisplay(report, shouldExcludeHiddenParticipants);
        return participantAccountIDs?.filter((accountID) => !!personalDetails?.[accountID]);
    }, [report, isGroupChat, isSystemChat, personalDetails]);

We can also check and do the same for workspace members too if needed.

What alternative solutions did you explore? (Optional)

[FitseTLT]

@stephanieelliott the title of the OP is a lit bit misleading as it suggests the problem is caused by using the secondary contact to invite the member but the problem is caused by the member being invited was a member with which the current user had no contact before. So to reproduce it, you should test by adding a member with which you had no contact before.
And also I suggest you update the title of the issue accordingly Thx. 👍

[bernhardoj]

Proposal

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

Inviting user we never chat before to a room will make an extra count to the room member count.

What is the root cause of that problem?

When we are searching for a new user, the app will generate a random optimistic account ID.

App/src/libs/OptionsListUtils.ts

Lines 1748 to 1749 in 5e65276

	// Generates an optimistic account ID for new users not yet saved in Onyx
	const optimisticAccountID = UserUtils.generateAccountID(searchValue);

When we invite the user, the app will optimistically merge the generated account ID to the room participants.

App/src/libs/actions/Report.ts

Lines 2809 to 2836 in 5e65276

	const participantsAfterInvitation = inviteeAccountIDs.reduce(
	(reportParticipants: Participants, accountID: number) => {
	const participant: ReportParticipant = {
	hidden: false,
	role: CONST.REPORT.ROLE.MEMBER,
	};
	// eslint-disable-next-line no-param-reassign
	reportParticipants[accountID] = participant;
	return reportParticipants;
	},
	{...report.participants},
	);
	const logins = inviteeEmails.map((memberLogin) => PhoneNumber.addSMSDomainIfPhoneNumber(memberLogin));
	const {newAccountIDs, newLogins} = PersonalDetailsUtils.getNewAccountIDsAndLogins(logins, inviteeAccountIDs);
	const newPersonalDetailsOnyxData = PersonalDetailsUtils.getPersonalDetailsOnyxDataForOptimisticUsers(newLogins, newAccountIDs);
	const pendingChatMembers = ReportUtils.getPendingChatMembers(inviteeAccountIDs, report?.pendingChatMembers ?? [], CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD);
	const optimisticData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	participants: participantsAfterInvitation,
	pendingChatMembers,
	},
	},
	];

However, we never clear the optimistic report participant. This logic is used for both invite to room and group, but the issue doesn't happen in a group chat because the API for invite to group chat returns a response when success that will clears the optimistic report participant.

The reason the optimistic participant disappears from the member list is because we skip over members that doesn't have personal details (which are cleared correctly when successful).

App/src/pages/RoomMembersPage.tsx

Lines 177 to 180 in 5e65276

	if (!details) {
	Log.hmmm(`[RoomMembersPage] no personal details found for room member with accountID: ${accountID}`);
	return;
	}

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

Fix it in the BE so invite to room also returns a response to clear the optimistic report participant.

OR

Fix it in the FE by clearing the optimistic report participant in success data.

const participantsSuccessData = inviteeAccountIDs.reduce(
    (reportParticipants, accountID: number) => ({...reportParticipants, [accountID]: null}),
    {},
);
const successData: OnyxUpdate[] = [
    {
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
        value: {
            participants: participantsSuccessData,
            pendingChatMembers: successPendingChatMembers,
        },
    },
];

[melvin-bot]

@stephanieelliott Whoops! This issue is 2 days overdue. Let's get this updated quick!

[stephanieelliott]

Thanks @FitseTLT! I see what you mean -- updated the title and action steps to make that more clear.

[stephanieelliott]

Given that it affects any user you've not previously had contact with (not secondary logins) and persists on the workspace, I think this is worth fixing. Adding labels to get the proposals reviewed.