[HOLD] [$4000] LHN- All chat icons turn green for a moment when user logs into High traffic account

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

Pre-Condition: Have a couple/several chats already open with other accounts

1. Access http://staging.new.expensify.com on mweb iOS
2. Log in to a high traffic account

Expected Result:

When the user is logged in, he/she expects to see the correct color user icons next to each chat window

Actual Result:

When the user logs in, all chats are shown with a green icon to the left of the name and after a couple of second the chat images switch to the actual colors (Yellow, blue, green, pink, etc.)

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Mobile Web

Version Number: 1.1.44.0

Reproducible in staging?: Yes

Reproducible in production?: Yes

Email or phone of affected tester (no customers): applausetester+ebezerra@applause.expensifail.com

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Bug5495370_Chat_icon_changing_colours.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause

Slack conversation:

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @aldo-expensify (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[aldo-expensify]

@kbecciv 👋 what is a "high traffic account"? is it an account with lots of chats?

[kbecciv]

@aldo-expensify Yes, account with more than 10K users.

[aldo-expensify]

I this only happening in mweb IOS? can you confirm if it happens in web (desktop) or native mobile?

[kbecciv]

@aldo-expensify Able to reproduce in Andriod app

[aldo-expensify]

This is related to this code:

App/src/libs/actions/PersonalDetails.js

Lines 166 to 211 in 7919e24

	API.PersonalDetails_GetForEmails({emailList: participantEmails.join(',')})
	.then((data) => {
	const existingDetails = _.pick(data, participantEmails);
	// Fallback to add logins that don't appear in the response
	const details = _.chain(participantEmails)
	.filter(login => !data[login])
	.reduce((previousDetails, login) => ({
	...previousDetails,
	[login]: {}, // Simply just need the key to exist
	}), existingDetails)
	.value();
	const formattedPersonalDetails = formatPersonalDetails(details);
	Onyx.merge(ONYXKEYS.PERSONAL_DETAILS, formattedPersonalDetails);
	// The personalDetails of the participants contain their avatar images. Here we'll go over each
	// report and based on the participants we'll link up their avatars to report icons. This will
	// skip over default rooms which aren't named by participants.
	const reportsToUpdate = {};
	_.each(reports, (report) => {
	if (report.participants.length <= 0 && !ReportUtils.isChatRoom(report) && !ReportUtils.isPolicyExpenseChat(report)) {
	return;
	}
	const avatars = OptionsListUtils.getReportIcons(report, details);
	const reportName = (ReportUtils.isChatRoom(report) || ReportUtils.isPolicyExpenseChat(report))
	? report.reportName
	: _.chain(report.participants)
	.filter(participant => participant !== currentUserEmail)
	.map(participant => lodashGet(
	formattedPersonalDetails,
	[participant, 'displayName'],
	participant,
	))
	.value()
	.join(', ');
	reportsToUpdate[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`] = {icons: avatars, reportName};
	});
	// We use mergeCollection such that it updates ONYXKEYS.COLLECTION.REPORT in one go.
	// Any withOnyx subscribers to this key will also receive the complete updated props just once
	// than updating props for each report and re-rendering had merge been used.
	Onyx.mergeCollection(ONYXKEYS.COLLECTION.REPORT, reportsToUpdate);
	});

The API command PersonalDetails_GetForEmails load some info like avatar, avatarThumbnail, firstName, etc. for a list of emails. I'll check if this can be fixed by improving the performance on the API side.

All users appear with the green avatar because their avatars have not loaded yet.

A possible improvement in the front could be to have a spinner as avatar while we wait for this API command to return, but maybe that could look weird.

[aldo-expensify]

I tested locally if the PersonalDetails_GetForEmails was slow to responde from the API, and it is fast (tested requesting data for 500 accounts), also, from looking at the code, I think it should be fast.

I think the problem may be that we are waiting for other requests to finish first before sending PersonalDetails_GetForEmails and this may be improved in the frontend, adding External.

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[JmillsExpensify]

Upwork job posted here: https://www.upwork.com/jobs/~011b8d95c6d7c31fe1

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Santhosh-Sellavel (Exported)

[melvin-bot]

Triggered auto assignment to @chiragsalian (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[JmillsExpensify]

Still waiting on contributors.

[JmillsExpensify]

Still waiting on contributors. I'm going to go ahead and update the price to $1000 since I missed updating to $500 last week.

[JmillsExpensify]

Still waiting for proposal so I'm increasing the price to $2,000.

[chiragsalian]

Still waiting on proposals.

[JmillsExpensify]

Moving the the price to $4000 since we're still waiting on proposals.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[JmillsExpensify]

I'll keep this open though I'm going to put it on hold. If we have another week where this isn't reproducible, I'll close.

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[JmillsExpensify]

Going to close this one since two weeks with no regression. Let's re-open if it crops up again.