[Due for payment 2026-03-30] Task - Assignee avatar is inconsistent in task & assignee page

[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.3.39-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: #85032
Email or phone of affected tester (no customers): dreamnitethedragon+yydyd373@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redminote 10S Android 13
App Component: Other

Action Performed:

1. Launch app
2. Open self dm
3. Create a task entering existing user as assignee
4. Open the task
5. Open the assignee

Expected Result:

Assignee avatar must be consistent in task & assignee page.

Actual Result:

Assignee avatar is inconsistent in task & assignee page.

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

Issue Owner

Current Issue Owner: @dukenv0307

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #85032 - "fix: Assigned task appears hidden and assignee status not shown" by @nkdengineer (High confidence)
Related Issues: #81714 (original issue that #85032 was fixing)

Recommendation: ROLL FORWARD

While PR #85032 can be cleanly reverted, rolling forward with a fix is the better approach because:

1. Reverting would reintroduce bug [$250] Task - Assigned task appears hidden and assignee status not shown #81714 (tasks assigned to new users appear "Hidden")
2. The fix is straightforward - the isOptimisticPersonalDetail flag is being set incorrectly for existing users
3. The root cause is well-understood and isolated to the logic in TaskAssigneeSelectorModal.tsx

Labels: Keeping DeployBlockerCash (App PR caused the issue, App deploy remains blocked)

📋 Detailed Analysis

Evidence

PR #85032 modified how optimistic personal details are handled when assigning tasks. The PR introduced tracking via the isOptimisticPersonalDetail flag to conditionally clear optimistic personal details on API success.

Key changes in PR #85032:

1. Added isOptimisticPersonalDetail flag to personal details
2. Changed TaskAssigneeSelectorModal.tsx line 155: isOptimisticPersonalDetail: !allPersonalDetails?.[option?.accountID ?? CONST.DEFAULT_NUMBER_ID]
3. Made clearing of personal details conditional in ReportUtils.ts (only clears if isOptimisticPersonalDetail(assigneeAccountID) returns true)

Verification

• PR fix: Assigned task appears hidden and assignee status not shown #85032 modified the affected files: src/libs/ReportUtils.ts, src/libs/actions/Task.ts, src/pages/tasks/TaskAssigneeSelectorModal.tsx
• The PR merged on 2026-03-16 at 20:50:46Z, which aligns with the staging-only reproduction
• Issue [Due for payment 2026-03-30] Task - Assignee avatar is inconsistent in task & assignee page #85532 is reproducible on staging (where fix: Assigned task appears hidden and assignee status not shown #85032 is deployed) but NOT on production (where it is not yet deployed)
• The issue specifically mentions avatar inconsistency when assigning tasks to existing users, which directly relates to the personal details handling changes in fix: Assigned task appears hidden and assignee status not shown #85032

Root Cause

The bug occurs in TaskAssigneeSelectorModal.tsx at line 155:

isOptimisticPersonalDetail: !allPersonalDetails?.[option?.accountID ?? CONST.DEFAULT_NUMBER_ID]

Problem: This logic incorrectly marks existing users as optimistic when their personal details simply haven't been loaded into the local allPersonalDetails object yet.

Flow of the bug:

1. User selects an existing user (who they haven't chatted with before) as task assignee
2. allPersonalDetails[accountID] is undefined/empty (not yet loaded)
3. Code sets isOptimisticPersonalDetail: true (incorrectly)
4. API call succeeds and returns real personal details
5. Success handler checks isOptimisticPersonalDetail(assigneeAccountID) which returns true
6. Personal details get cleared: {[assigneeAccountID]: null}
7. Avatar becomes inconsistent - task page shows one avatar, assignee page shows fallback/default avatar

Why this breaks:

• Before fix: Assigned task appears hidden and assignee status not shown #85032: Personal details were always cleared on success, which was also wrong but manifested differently
• After fix: Assigned task appears hidden and assignee status not shown #85032: Personal details are conditionally cleared, but the condition incorrectly identifies existing users as optimistic
• The isOptimisticPersonalDetail flag should distinguish between "truly new user" vs "existing user whose details aren't loaded yet"

Recommended fix approach:
The fix should ensure that isOptimisticPersonalDetail is only set to true for genuinely new/optimistic users, not for existing users whose personal details happen to be unloaded. This might require checking additional signals (e.g., whether the user exists in the backend) or preserving the personal details differently.

[MelvinBot]

Proposal

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

When creating a task and assigning it to an existing user, the assignee's avatar is inconsistent between the task detail view and the assignee's page. This regression was introduced in staging by PR #85032.

What is the root cause of that problem?

PR #85032 changed getTaskAssigneeChatOnyxData in src/libs/ReportUtils.ts to only null out the assignee's personal details on API success for optimistic (new) users. For existing users, the null-out is now skipped.

The problem lies in setNewOptimisticAssignee (src/libs/actions/Task.ts:878-885). When called for an existing user (who has no 1:1 DM chat with the current user), it merges a partial personal details object (only 5 fields: accountID, avatar, displayName, login, isOptimisticPersonalDetail) into ONYXKEYS.PERSONAL_DETAILS_LIST via Onyx.merge.

Before PR #85032:

1. setNewOptimisticAssignee merges partial personal details
2. On API success, the success callback nulls the entire entry ({[assigneeAccountID]: null})
3. The backend response then writes fresh, complete personal details
4. Both the task view and assignee page show the correct, server-provided avatar

After PR #85032:

1. setNewOptimisticAssignee merges partial personal details (with isOptimisticPersonalDetail: false for existing users)
2. On API success, the success callback skips the null (because isOptimisticPersonalDetail() returns false)
3. The backend response merges on top, but the partial optimistic data persists
4. The task view (via useReportActionAvatars at src/components/ReportActionAvatars/useReportActionAvatars.ts:128) reads personalDetails?.[id]?.avatar ?? FallbackAvatar
5. The profile page (via openPublicProfilePage) fetches fresh data from the server, updating the avatar

The inconsistency arises because the task view uses the locally-stored (potentially stale) avatar, while navigating to the assignee triggers a fresh server fetch that returns the canonical avatar.

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

In setNewOptimisticAssignee (src/libs/actions/Task.ts:878-885), skip the Onyx.merge into PERSONAL_DETAILS_LIST when the user already exists (i.e., when isOptimisticPersonalDetail is false). The merge into personal details is only needed for truly new/optimistic users whose data doesn't exist in the store yet. For existing users, their personal details are already in PERSONAL_DETAILS_LIST and don't need to be overwritten with a partial object.

Specifically, wrap the existing Onyx.merge call at line 885 with a condition:

if (assigneePersonalDetails.isOptimisticPersonalDetail) {
    Onyx.merge(ONYXKEYS.PERSONAL_DETAILS_LIST, {[assigneePersonalDetails.accountID]: optimisticPersonalDetailsListAction});
}

This preserves the fix from PR #85032 (not nulling existing users on success) while preventing the partial overwrite that causes avatar inconsistency.

What alternative solutions did you explore? (Optional)

1. Revert the isOptimisticPersonalDetail condition in getTaskAssigneeChatOnyxData — This would re-introduce the original bug from issue [$250] Task - Assigned task appears hidden and assignee status not shown #81714 (task appearing hidden for existing users).

2. Make the optimistic object include ALL personal details fields — This would mean copying the full personal details into the optimistic object. While it would prevent data loss, it adds complexity and the merge is still unnecessary for existing users.

3. Keep the null-out but immediately re-merge the existing data — Overly complex and still has a brief flicker where data is null.

---

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.