[Due for payment][$125] Tasks - Fallback avatar remains when new user is assignee

[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: v9.2.37-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #71446
Email or phone of affected tester (no customers): gocemate+b2154681@gmail.com
Issue reported by: Applause Internal Team
Device used: Lenovo 80ES / Windows 10 Pro
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Go to 1:1 DM
3. Create new task
4. Open task details page
5. Click on Assignee
6. Enter new email user and select it
7. Verify new user is now assignee and default avatar is displayed
8. Click on Assignee again

Expected Result:

User's avatar should be default

Actual Result:

Fallback avatar remains on Assignee page when new user is promoted as assignee

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021981712846843185514
• Upwork Job ID: 1981712846843185514
• Last Price Increase: 2025-10-31
• Automatic offers:
• FitseTLT | Reviewer | 109359205
• mkzie2 | Contributor | 109359209

Issue Owner

Current Issue Owner: @twisterdotcom

[melvin-bot]

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

[coderyak]

Proposal

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

When a new user is added as a task assignee, the fallback avatar remains on the Assignee page instead of showing the default avatar. The user expects to see a default avatar (not the fallback avatar) when a new user is promoted as assignee.

What is the root cause of that problem?

The issue occurs in src/components/ReportActionAvatars/useReportActionAvatars.ts at line 119 where the avatar source is determined:

source: personalDetails?.[id]?.avatar ?? FallbackAvatar,

When a new user is added as an assignee, their personal details are not yet fully loaded from the server, so personalDetails?.[id]?.avatar is undefined. This causes the avatar to fall back to FallbackAvatar instead of using the proper default avatar that should be generated based on the account ID.

The getDefaultAvatar function in src/libs/UserUtils.ts provides the correct default avatar based on the account ID, but it's not being used in this context.

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

Modify the avatar source logic in useReportActionAvatars.ts to use the getDefaultAvatarURL function when personal details are not available, instead of falling back to FallbackAvatar.

The current code has:

source: personalDetails?.[id]?.avatar ?? FallbackAvatar,

Should be changed to:

source: personalDetails?.[id]?.avatar ?? getDefaultAvatarURL(id) ?? FallbackAvatar,

This ensures that when personal details are not yet loaded, the system will try to generate a default avatar based on the account ID before falling back to the generic fallback avatar.

What alternative solutions did you explore? (Optional)

1. Wait for personal details to load: This would require adding loading states and re-rendering when personal details become available, which could cause UI flickering and delays.

2. Always use default avatar for new users: This could show inappropriate avatars for users who have custom avatars but haven't loaded yet.

3. Cache default avatars: This would require additional complexity to manage avatar caching and could lead to stale data issues.

[akinwale]

@abzokhattab Could you have a look and check if this was due to the refactor?

[twisterdotcom]

Will wait for @abzokhattab to chime in here.

[abzokhattab]

Checked out to the commit before the merge and was still able to reproduce it. This issue was present before the refactor. So it's not related.

Screen.Recording.2025-10-24.at.15.18.00.mov

cc @akinwale @twisterdotcom

[twisterdotcom]

Okay.... I guess let's fix it. Very niche though.

[melvin-bot]

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