Profile - Avatar changes to non-letter avatar after saving letter avatar

[applause-bot]

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.4.43-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: #96269
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: User Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Create a new Gmail account.
3. Complete onboarding with Managa my team's expenses.
4. Go to Account > Profile.
5. Click on the avatar.
6. Select any letter avatar and save it.

Expected Result:

The selected letter avatar will be saved.

Actual Result:

Avatar changes to non-letter avatar after saving letter avatar.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7214960_1784758619791.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7214960

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f277513aef331410f05e9f75b8633135e3410942f60c1faf0d3afb07ecb569f8

[melvin-bot]

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

[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]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96269 - "Let users pick a letter avatar color" by @grgia (High confidence)
Related Issues: #93810 (the feature issue this PR implemented)

Recommendation: REVERT

The regression is entirely contained in this single feature PR (letter-avatar color picking), it is not yet in production, and it carries a cross-repo Auth/Web dependency ("requires the Auth and Web changes to be deployed to staging first"), so a clean revert is safer than a targeted hotfix under deploy-blocker time pressure.

Assigned: @grgia (PR author), @bernhardoj (approving reviewer), @mjasikowski (approving reviewer) from the highest-confidence causing PR only
Labels: No label changes. Kept DeployBlockerCash — this is a frontend bug fixed in Expensify/App, and the issue is not reproducible in production, so the App-deploy blocker must remain. No DeployBlocker (Web) label was present.

📋 Detailed Analysis

Evidence

• PR Let users pick a letter avatar color #96269 is in the current StagingDeployCash (Deploy Checklist: New Expensify 2026-07-22 #96786) and is the only PR in the release that touches avatar / letter-avatar / default-avatar selection and rendering. It merged 2026-07-22, matching when the bug first appeared on staging.
• The issue itself is N/A in production because the entire "pick a letter avatar color" feature is new and only exists on staging via this PR — the symptom cannot pre-date it.
• The PR rewrites the whole letter-avatar pipeline: it deletes ColoredLetterAvatar.tsx, replaces useLetterAvatars.tsx, adds updateAvatarStyle, reworks Avatar.tsx rendering, and changes getDefaultAvatarURL. The reported flow (select a letter avatar → save) is driven directly by code this PR introduced.

Verification

Affected files this PR modifies (confirmed via gh pr view 96269 --json files):

• src/pages/settings/Profile/Avatar/useProfileAvatarForm.ts — the save handler
• src/libs/actions/PersonalDetails.ts — new updateAvatarStyle action
• src/components/Avatar.tsx — letter-avatar render path
• src/libs/UserAvatarUtils.ts — getDefaultAvatarURL / getLetterAvatarURL / getLetterAvatarInitials

Root Cause

Saving a picked letter color does not reliably produce a letter avatar at render time; it can fall back to a numbered (non-letter) default.

1. Save flow: useProfileAvatarForm.save() calls updateAvatarStyle(selected, currentUserPersonalDetails) when a letter scheme key is selected (useProfileAvatarForm.ts lines 108-113).

2. Inside updateAvatarStyle (PersonalDetails.ts), the picked color is stored in avatarStyle.color, and because a fresh "Manage my team's expenses" account has a backend-assigned numbered default avatar (.../default-avatar_N.png, which is not a generated-letter URL), the guard
   willClearAvatar = !!avatar && !isGeneratedLetterAvatarURL(avatar) is true.
   The optimistic update therefore overwrites avatar with getDefaultAvatarURL({accountID, accountEmail, firstName, lastName}).

3. getDefaultAvatarURL (UserAvatarUtils.ts line 142) does not use the picked color. It calls getLetterAvatarURL(...), which derives its color by hashing the login/accountID and returns '' (falling through to a numbered default-avatar_N) whenever getLetterAvatarInitials(firstName, lastName, login) yields no initials.

4. The render path is the core defect. Avatar.tsx line 139/167 only renders a letter avatar when parseLetterAvatarURL(source) is truthy, i.e. only when the avatar URL is itself a generated-letter URL. The picked avatarStyle.color is consulted exclusively inside UserLetterAvatar as a color override on an already-generated letter URL — it is never used to promote a non-letter avatar into a letter avatar. So whenever step 3 leaves a numbered default-avatar_N as the source, the picked color is silently ignored and the user sees a non-letter default avatar — exactly the reported symptom.

In short: the feature couples "which avatar type is rendered" to the stored avatar URL, but couples "which color the letter uses" to avatarStyle.color. When the optimistic/backend avatar is not a generated-letter URL, those two paths disagree and the letter avatar is dropped. This is a frontend logic gap; combined with the PR's stated Auth/Web deploy dependency, reverting from Expensify/App is the correct resolution.