[Due for payment 2026-09-09] Workspace - Members avatar become fallback when clear cache

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.60-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/70698814/folder/53678195?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocemate+sdf@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: windows 10/chrome
App Component: Chat Report View

Action Performed:

1. Create workspace and invite members
2. Go to Troubleshoot
3. Tap Clear cache and restart
4. Navigate to workspace members page

Expected Result:

Members should be displayed with default or custom avatars

Actual Result:

Avatars of the workspace members are displayed as fallback

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7241816_1787612955182.Recording__1477.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @gijoe0295

[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/57c32be7270c6882528db855d2d1ef14c278dfe0ed1a3eb1f43c07c7f1e2d234

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

[melvin-bot]

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #98483 - "Show workspace members with missing personal details instead of dropping them" by @gijoe0295 (High confidence)
Related Issues: #97591 (the issue #98483 was fixing)

Recommendation: ROLL FORWARD

A straight revert of #98483 would reintroduce the original bug it fixed (workspace members being silently dropped from the list, #97591), which is arguably worse than a fallback avatar. The targeted fix is to seed a deterministic default avatar from the member's email when personal details are missing, instead of rendering the generic gray FallbackAvatar.

Assigned: @gijoe0295 (PR author/co-author), @luacmartins, @justinpersaud (approving reviewers) from the highest-confidence causing PR
Labels: No change. This is a Frontend bug, so DeployBlockerCash correctly stays; no DeployBlocker was present to remove.

📋 Detailed Analysis

Evidence

• Bug reproduces on staging (9.4.60-0) but not production, so the cause is a PR in this deploy.
• Show workspace members with missing personal details instead of dropping them #98483 is in the 9.4.60 StagingDeployCash (merged 2026-08-24) and directly rewrote the filteredMembers logic on the Workspace Members page.
• Before Show workspace members with missing personal details instead of dropping them #98483, members whose personal details weren't loaded were skipped (continue) and dropped from the list. Show workspace members with missing personal details instead of dropping them #98483 now renders them using a generated (synthetic) accountID and a fallback identity that has no avatar.
• The "Clear cache and restart" step wipes Onyx personal details. When the members page renders before personal details reload, every member hits the missing-details path introduced by Show workspace members with missing personal details instead of dropping them #98483 → the avatar resolves to the generic gray FallbackAvatar. This exactly matches the reported symptom ("Avatars of the workspace members are displayed as fallback").
• The avatar-resolution primitives (buildUserIcon / useAccountIcons) were already in production (from ReportActionAvatars -> UserAvatar for multi avatars migration + leftovers #97983), so they are not the regression on their own — Show workspace members with missing personal details instead of dropping them #98483 is what began feeding them synthetic accountIDs with no avatar/email seed.

Verification

• Affected feature files:
  • src/pages/workspace/WorkspaceMembersPage.tsx — filteredMembers builds accountID = policyMemberEmailsToAccountIDs[email] ? Number(...) : generateAccountID(email) and a fallback details object with no avatar.
  • src/components/Tables/WorkspaceMembersTable/WorkspaceMembersTableRow.tsx — passes accountID={item.accountID} to AccountAvatar with no email.
  • src/components/Avatar/connected/AccountAvatar.tsx → useAccountIcons.ts → buildUserIcon in src/libs/UserAvatarUtils.ts#L521-L530.
• git log/GitHub API confirms Show workspace members with missing personal details instead of dropping them #98483 (merge commit 22ab94c) is the only in-deploy PR touching WorkspaceMembersPage.tsx's member-filtering logic.
• generateAccountID(email) = hashText(email, 2**32) (src/libs/UserUtils.ts#L215-L217) — a synthetic hash that will never match a real personalDetails key.

Root Cause

When personal details are absent (e.g. right after Clear cache, before re-fetch), policyMemberEmailsToAccountIDs[email] is empty, so filteredMembers assigns a synthetic accountID = generateAccountID(email). That ID is passed to AccountAvatar → useAccountIcons → buildUserIcon, where:

source: personalDetails?.[accountID]?.avatar ?? defaultAvatars.FallbackAvatar,
...
fallbackIcon: invitedEmail ? getDefaultAvatar({accountID, accountEmail: addSMSDomainIfPhoneNumber(invitedEmail), defaultAvatars}) : undefined,

personalDetails?.[syntheticAccountID]?.avatar is undefined, and because these are existing members (no invitedEmail), fallbackIcon is also undefined. So the row renders the generic gray FallbackAvatar instead of the deterministic default/letter avatar that would be computed from the member's email/name. The proper roll-forward fix is to pass the member's email into the avatar resolution (as invited-member rows already do) so getDefaultAvatar/getLetterAvatarURL produces a stable default avatar when personal details are missing.