Expense - Attendees field does not update to custom avatar

[jponikarchuk]

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.52-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85332
Email or phone of affected tester (no customers): jsoidjniosdjoisnjdisoj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Rules are enabled.
• Attendee tracking is enabled in Rules.
• Account does not have custom avatar.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses.
4. Go to Account > Profile.
5. Upload a custom avatar.
6. Go to Inbox.
7. Open the expense report from Step 3.

Expected Result:

Attendees field will show the custom avatar.

Actual Result:

Attendees field still shows default avatar after uploading custom avatar.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #85332

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

When attendees are added to an expense, their avatar URL is captured as a snapshot and stored in transaction.comment.attendees[].avatarUrl (see TransactionUtils/index.ts:1180). When the user later uploads a custom avatar, personalDetails in Onyx updates but the stored attendee data in the transaction does not.

AttendeesCell.tsx:33 resolves avatars as:

attendee.avatarUrl || getDefaultAvatar(...)

So it uses the stale stored URL (which was the default avatar at creation time) instead of the user's current avatar from personalDetails.

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

In AttendeesCell.tsx, when building attendeeIcons, prefer the live avatar from personalDetails (already fetched on line 42) over the stale attendee.avatarUrl stored in the transaction.

When an attendee.accountID is available and matches an entry in personalDetails, use personalDetails[accountID].avatar (or avatarThumbnail) instead of attendee.avatarUrl. Fall back to attendee.avatarUrl only when the attendee has no matching personal details entry (e.g., external attendees without an Expensify account).

Investigation details

Data flow:

1. getReportOwnerAsAttendee() (TransactionUtils/index.ts:1155-1185) captures creatorDetails.avatarThumbnail ?? creatorDetails.avatar at expense creation time and stores it in avatarUrl
2. getAttendees() (TransactionUtils/index.ts:1207-1216) returns stored attendees from transaction.comment.attendees — these contain the stale avatarUrl
3. TransactionItemRow (line 277) passes these to AttendeesCell
4. AttendeesCell (line 33) uses the stale avatarUrl first, only falling back to getDefaultAvatar() if it's empty

Why getDefaultAvatar fallback doesn't help: If the user had a default SVG avatar (no uploaded photo), the stored avatarUrl would be an empty string, and getDefaultAvatar would generate the correct colored default. But once a user uploads an avatar and the transaction already has attendees stored, the stored avatarUrl still points to the old value.

Note: personalDetails is already available in AttendeesCell (line 42) — it's used for sorting but not for avatar resolution.

What alternative solutions did you explore?

An alternative would be to update the stored avatarUrl in all transactions whenever a user changes their avatar (via an Onyx subscriber or API-side). This would be more complex and less efficient since it requires updating potentially many transactions, whereas the rendering-layer fix is simple and always shows the latest data.

---

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.

[nkdengineer]

@justinpersaud We can demote this, we discussed about this in the PR and it's a backend issue.