[$250] Invited member to expense report sees the chat with fallback avatar on LHN

[nlemma]

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.3.37-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://github.com/Expensify/Expensify/issues/575565
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows Windows 10
App Component: Other

Action Performed:

Have 3 user accounts - User A, User B, and User C
As User C navigate to account page

1. Go to staging.new.expensify.com
2. [User A] Submit two expenses to User B.
3. [User A] Go to the expense report.
4. [User A] Send a message containing User C mention.
5. [User A] Invite User C by clicking Invite them on the whisper.
6. [User C] navigate to inbox
7. [User C] Check when chat appears on LHN

Expected Result:

There should be default avatar

Actual Result:

When User C is invited to expenses report - chat with fallback avatar appears on LHN

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7086676_1771912414797.bandicam_2026-02-24_08-48-01-977.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @hoangzinh

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022032473098114010073
• Upwork Job ID: 2032473098114010073
• Last Price Increase: 2026-03-13

[MelvinBot]

Proposal

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

When User C is invited to an expense report (via @mention + invite whisper), the chat appears on the LHN with a generic gray silhouette avatar (the "fallback avatar") instead of the proper colorful default avatar that should be deterministically assigned to the report owner based on their accountID.

What is the root cause of that problem?

The icon-building functions in ReportUtils.ts fall back to the FallbackAvatar SVG (a generic gray silhouette) when a user's personal details haven't been loaded into Onyx yet, even though the accountID is known and available.

Specifically, getIconsForExpenseReport (ReportUtils.ts:3766-3773) calls getParticipantIcon(report.ownerAccountID, personalDetails) to build the owner's avatar. Inside getParticipantIcon (ReportUtils.ts:3593-3611), when personalDetails[ownerAccountID] is undefined (not yet loaded for User C's session), the code evaluates:

source: details?.avatar ?? FallbackAvatar  // → FallbackAvatar (gray silhouette)
fallbackIcon: details?.fallbackIcon        // → undefined

The Avatar component (Avatar.tsx:88-98) then calls getAvatar({avatarSource: FallbackAvatar, accountID}), but isDefaultAvatar(FallbackAvatar) returns false (because FallbackAvatar is an SVG component, not a URL string), so getDefaultAvatar({accountID}) is never called. The Avatar renders the gray silhouette.

The app has a system that can generate colorful, personalized default avatars from just the accountID (via getDefaultAvatar({accountID}) in UserAvatarUtils.ts:88-97), but the icon-building functions bypass it when personal details are missing.

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

In getParticipantIcon (ReportUtils.ts:3607), when personal details are missing but the accountID is known, use getDefaultAvatarURL({accountID}) instead of FallbackAvatar as the avatar source. This way the Avatar component will resolve it to the correct colorful default avatar via getAvatar → isDefaultAvatar → getDefaultAvatar.

The same fix should be applied to getIconsForParticipants (ReportUtils.ts:3325) and getIconsForIOUReport (ReportUtils.ts:3786, 3794), which have the identical details?.avatar ?? FallbackAvatar pattern.

What alternative solutions did you explore? (Optional)

1. Fix in Avatar.tsx: When useFallBackAvatar is true and avatarID is available, compute a default avatar from the ID. This would be a catch-all but is less targeted and adds complexity to an already complex rendering path.
2. Fix in getAvatar (UserAvatarUtils.ts): Add a check for the FallbackAvatar SVG component alongside the string-based isDefaultAvatar check. This would work but is more of a workaround since the real issue is that FallbackAvatar shouldn't be set as the source in the first place when the accountID is available.
3. Ensure personal details are always loaded before rendering: This would require changes to the data fetching layer, is harder to guarantee, and the UI should still handle missing data gracefully.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[jainam884]

🚨 Edited by proposal-police: This proposal was edited at 2026-03-19 05:16:16 UTC.

Proposal

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

When User C is invited to an expense report and opens the LHN before that report owner’s personal details are hydrated in Onyx, the report row renders a generic fallback silhouette avatar instead of the deterministic default avatar.

What is the root cause of that problem?

For expense report icons, we build the member avatar with getParticipantIcon(), which currently sets source to details?.avatar ?? FallbackAvatar. In the invite flow, personalDetails[ownerAccountID] can be temporarily missing for the newly invited user, so the source becomes the FallbackAvatar SVG.

Avatar then calls getAvatar(), but default-avatar resolution is string-pattern based. Since FallbackAvatar is an SVG asset (not a default-avatar URL string), getAvatar() does not map it to the accountID-based default avatar and the gray fallback remains visible.

App/src/libs/ReportUtils.ts

Lines 3578 to 3596 in 1d43910

	}
	const receiverPolicyID = report?.invoiceReceiver?.policyID;
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const receiverPolicy = invoiceReceiverPolicy ?? getPolicy(receiverPolicyID);
	if (!isEmptyObject(receiverPolicy)) {
	return [
	{
	source: receiverPolicy?.avatarURL ?? getDefaultWorkspaceAvatar(receiverPolicy.name),
	type: CONST.ICON_TYPE_WORKSPACE,
	name: receiverPolicy.name,
	id: receiverPolicyID,
	},
	];
	}
	return [];
	}

App/src/components/Avatar.tsx

Lines 88 to 98 in 1d43910

	const isWorkspace = type === CONST.ICON_TYPE_WORKSPACE;
	const userAccountID = isWorkspace ? undefined : (avatarID as number);
	const source = isWorkspace ? originalSource : getAvatar({avatarSource: originalSource, accountID: userAccountID, defaultAvatars});
	let optimizedSource = source;
	const maybeDefaultAvatarName = getPresetAvatarNameFromURL(source);
	if (maybeDefaultAvatarName) {
	optimizedSource = getAvatarLocal(maybeDefaultAvatarName);
	}
	const useFallBackAvatar = imageError || !source || source === defaultAvatars.FallbackAvatar;

App/src/libs/UserAvatarUtils.ts

Lines 218 to 228 in 1d43910

	function getAvatar({avatarSource, accountID = CONST.DEFAULT_NUMBER_ID, accountEmail, defaultAvatars}: GetAvatarArgsType & DefaultAvatarsType): AvatarSource | undefined {
	if (isDefaultAvatar(avatarSource)) {
	return getDefaultAvatar({accountID, accountEmail, avatarURL: avatarSource, defaultAvatars});
	}
	const maybePresetAvatarName = getPresetAvatarNameFromURL(avatarSource);
	if (maybePresetAvatarName) {
	return avatarCatalogGetAvatarLocal(maybePresetAvatarName);
	}
	return avatarSource;

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

When an accountID is known but personal details are missing, set the avatar source to getDefaultAvatarURL({accountID}) instead of FallbackAvatar.

Apply this in:

• getParticipantIcon() (covers expense report avatar rendering path from this issue)
• getIconsForParticipants() and getIconsForIOUReport() (same fallback pattern, keeps behavior consistent across report types)

Keep FallbackAvatar only for truly unknown account IDs (for example undefined/invalid IDs).

This makes newly visible reports immediately render the correct deterministic default avatar, and still allows automatic replacement with uploaded avatars once personal details finish loading.

What alternative solutions did you explore? (Optional)

1. Update Avatar/getAvatar to special-case FallbackAvatar + accountID and synthesize a default avatar there. This is broader and less targeted because it changes global avatar resolution semantics.
2. Block report-row rendering until all personal details are loaded. This increases coupling to async data hydration and can delay UI updates.
3. Use fallbackIcon for this case. It is not guaranteed to be present when personal details are absent, so it does not reliably fix the issue.

[ProjectNOVACo]

Proposal

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

When User C is invited to an expense report via @mention and invite whisper, the chat appears on the LHN with a generic gray fallback avatar instead of the deterministic colorful default avatar tied to the report owner's accountID.

What is the root cause of that problem?

The icon-building chain in ReportUtils.ts uses FallbackAvatar (an SVG component) as the fallback when personal details are not yet loaded, but the Avatar rendering pipeline cannot resolve SVG components to personalized default avatars.

Full data flow trace:

1. User C's session receives the expense report via Pusher/Onyx sync. At this point, personalDetails[ownerAccountID] may not yet be hydrated for User C's Onyx store.

2. The LHN calls getIcons() → getIconsForExpenseReport() (ReportUtils.ts:3767), which calls getParticipantIcon(report.ownerAccountID, personalDetails) at line 3772.

3. Inside getParticipantIcon() (lines 3564-3583), the accountID is valid (non-zero), so the early return for missing accountID is skipped. However, personalDetails[accountID] is undefined, so:

   source: details?.avatar ?? FallbackAvatar  // → FallbackAvatar (SVG component)
   fallbackIcon: details?.fallbackIcon         // → undefined
   

4. The Avatar component (Avatar.tsx:88) calls getAvatar({avatarSource: FallbackAvatar, accountID: userAccountID}).

5. Inside getAvatar() (UserAvatarUtils.ts:218-229), the first check is isDefaultAvatar(avatarSource). The isDefaultAvatar() function (lines 159-173) only recognizes string URLs containing default avatar patterns — FallbackAvatar is an SVG component (not a string), so isDefaultAvatar() returns false.

6. Since isDefaultAvatar is false, getAvatar() skips getDefaultAvatar({accountID}) and returns the raw FallbackAvatar SVG component unchanged.

7. Back in Avatar.tsx:95, the comparison source === defaultAvatars.FallbackAvatar evaluates to true, setting useFallBackAvatar = true. The component renders the generic gray silhouette.

The critical gap: when accountID is known but personal details are absent, the code sets source to the FallbackAvatar SVG, which bypasses the isDefaultAvatar() → getDefaultAvatar() pipeline that would compute the personalized colorful avatar from the accountID.

The same pattern exists in 5 other locations in ReportUtils.ts:

• getIconsForParticipants() (line 3296): personalDetails?.[accountID]?.avatar ?? FallbackAvatar
• getIconsForExpenseRequest() (line 3636): actorDetails?.avatar ?? FallbackAvatar
• getIconsForChatThread() (line 3663): actorDetails?.avatar ?? FallbackAvatar
• getIconsForIOUReport() (line 3757): managerDetails?.avatar ?? FallbackAvatar
• getIconsForIOUReport() (line 3765): ownerDetails?.avatar ?? FallbackAvatar

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

Use getDefaultAvatarURL({accountID}) instead of FallbackAvatar as the fallback when accountID is known. This produces a default avatar URL string that isDefaultAvatar() recognizes, allowing the full getAvatar() → getDefaultAvatar() pipeline to resolve the personalized colorful avatar.

Primary fix in getParticipantIcon() (ReportUtils.ts:3564-3583):

+import {getDefaultAvatarURL} from @libs/UserAvatarUtils;
+
 function getParticipantIcon(accountID: number | undefined, personalDetails: OnyxInputOrEntry<PersonalDetailsList>, shouldUseShortForm = false): Icon {
     if (\!accountID) {
         return {
             id: CONST.DEFAULT_NUMBER_ID,
             source: FallbackAvatar,
             type: CONST.ICON_TYPE_AVATAR,
             name: ,
         };
     }
     const details = personalDetails?.[accountID];
     const displayName = getDisplayNameOrDefault(details, , shouldUseShortForm);
 
     return {
         id: accountID,
-        source: details?.avatar ?? FallbackAvatar,
+        source: details?.avatar ?? getDefaultAvatarURL({accountID}),
         type: CONST.ICON_TYPE_AVATAR,
         name: displayName,
         fallbackIcon: details?.fallbackIcon,
     };
 }

Apply the same fix to getIconsForParticipants() (line 3296):

 for (const accountID of participantsList) {
-    const avatarSource = personalDetails?.[accountID]?.avatar ?? FallbackAvatar;
+    const avatarSource = personalDetails?.[accountID]?.avatar ?? getDefaultAvatarURL({accountID});

Apply to getIconsForExpenseRequest() (line 3636):

     const memberIcon = {
-        source: actorDetails?.avatar ?? FallbackAvatar,
+        source: actorDetails?.avatar ?? (parentReportAction?.actorAccountID ? getDefaultAvatarURL({accountID: parentReportAction.actorAccountID}) : FallbackAvatar),

Apply to getIconsForChatThread() (line 3663):

     const actorIcon = {
         id: actorAccountID,
-        source: actorDetails?.avatar ?? FallbackAvatar,
+        source: actorDetails?.avatar ?? (actorAccountID ? getDefaultAvatarURL({accountID: actorAccountID}) : FallbackAvatar),

Apply to getIconsForIOUReport() (lines 3757, 3765):

     const managerIcon = {
-        source: managerDetails?.avatar ?? FallbackAvatar,
+        source: managerDetails?.avatar ?? (report?.managerID ? getDefaultAvatarURL({accountID: report.managerID}) : FallbackAvatar),

     const ownerIcon = {
         id: report?.ownerAccountID,
-        source: ownerDetails?.avatar ?? FallbackAvatar,
+        source: ownerDetails?.avatar ?? (report?.ownerAccountID ? getDefaultAvatarURL({accountID: report.ownerAccountID}) : FallbackAvatar),

Why this approach:

• getDefaultAvatarURL({accountID}) returns a CloudFront CDN URL string like https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/default-avatar_7.png, which isDefaultAvatar() recognizes (it checks for default avatar URL patterns in the string).
• This means the Avatar component's getAvatar() call flows through the correct pipeline: isDefaultAvatar(url) → true → getDefaultAvatar({accountID}) → personalized SVG component.
• FallbackAvatar is only used when accountID is truly unknown (undefined/zero), which is the correct semantic — the gray silhouette should only appear when we genuinely cannot determine who the user is.
• Once personal details load via Onyx, the avatar property becomes non-null and takes precedence over the fallback, so the fix is self-correcting.

Why alternatives are inferior:

1. Fixing in Avatar.tsx (when useFallBackAvatar && avatarID is available): This adds complexity to an already complex rendering component and still shows FallbackAvatar briefly before computing the default — the icon-building layer is the right place to fix this.
2. Fixing in getAvatar() to handle SVG FallbackAvatar: This would add a special case for an SVG component alongside string-based checks, which is a workaround rather than addressing the root cause.
3. Ensuring personal details load before rendering: This requires changes to the data fetching layer and delays UI rendering — the UI should handle missing data gracefully.

What alternative solutions did you explore? (Optional)

See above. The proposed fix addresses the root cause at the icon-building layer where the incorrect fallback is chosen, rather than patching downstream rendering logic. It follows the existing pattern where other code paths already use getDefaultAvatarURL() for URL-based avatar resolution.

Codebase-wide audit: I searched all icon-building functions in ReportUtils.ts and identified all 6 locations using the ?? FallbackAvatar pattern. The fix covers all of them to prevent the same issue from manifesting in other report types (IOU reports, chat threads, expense requests, group chats).

[ReaperOAK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @ReaperOAK Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[melvin-bot]

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