[$250] Task - App crashes on changing task assignee

[lanitochka17]

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.41
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85539
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: Chat Report View

Action Performed:

1. Launch app (use expensifail account)
2. Open self DM
3. Create task with existing user as assignee ( select from contacts)
4. Open the task - assignee
5. Select another existing user from contacts

Expected Result:

App must not crash on changing task assignee.

Actual Result:

App crashes on changing task assignee.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7108016_1773989162306.Screenrecorder-2026-03-20-12-14-34-185.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022035049602794748573
• Upwork Job ID: 2035049602794748573
• Last Price Increase: 2026-03-20

[MelvinBot]

Proposal

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

The app crashes on Android when changing a task assignee. Steps: open self DM → create task with an existing user as assignee → open the task → tap assignee → select another existing user from contacts → crash.

What is the root cause of that problem?

The crash was introduced by PR #85539 which modified getTaskAssigneeChatOnyxData in src/libs/ReportUtils.ts. That PR moved the participants: {[assigneeAccountID]: null} cleanup from the unconditional success data block into a conditional that only runs when isOptimisticPersonalDetail(assigneeAccountID) is true.

When changing the assignee to an existing user you've never chatted with:

1. setNewOptimisticAssignee (src/libs/actions/Task.ts:919-938) creates an optimistic chat report and personal details entry via Onyx.set and Onyx.merge
2. editTaskAssignee calls getTaskAssigneeChatOnyxData which enters the optimistic report block (line 10447)
3. Before the PR: On API success, participants: {[assigneeAccountID]: null} was applied to the assignee chat report, letting the BE response populate the correct participant data
4. After the PR: For existing users, isOptimisticPersonalDetail() returns false, so the participant cleanup is skipped. The optimistic participant entry persists alongside the BE response data

Additionally, the failure data at ReportUtils.ts:10531-10538 unconditionally deletes the personal details of the assignee ({[assigneeAccountID]: null}) even when they are an existing real user. If the EditTaskAssignee API call fails for any reason (network issue, server error), the personal details of the selected user are removed from Onyx, causing null reference errors in components that render that user's information.

The combination of these issues — stale optimistic participant data on success and destructive personal details deletion on failure — causes the Android crash during the assignee change flow.

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

In src/libs/ReportUtils.ts, in the getTaskAssigneeChatOnyxData function:

1. Restore unconditional participant cleanup on success (revert the participant-related part of PR fix: Assignee avatar is inconsistent in task & assignee page #85539): Move participants: {[assigneeAccountID]: null} back to the unconditional success data block (around line 10473-10497) so it runs for both optimistic and non-optimistic personal details. The avatar inconsistency from issue [Due for payment 2026-03-30] Task - Assignee avatar is inconsistent in task & assignee page #85532 should be solved differently — perhaps by ensuring the BE response always takes precedence over optimistic data rather than preventing cleanup.

2. Guard the failure data personal details deletion: At line 10531-10538, only delete the assignee's personal details on failure if isOptimisticPersonalDetail(assigneeAccountID) is true. This prevents deleting real users' personal details on API failure:

   if (isOptimisticPersonalDetail(assigneeAccountID)) {
       failureData.push({
           onyxMethod: Onyx.METHOD.MERGE,
           key: ONYXKEYS.PERSONAL_DETAILS_LIST,
           value: { [assigneeAccountID]: null },
       });
   }
   

3. Remove the duplicate isOptimisticReport: false success data entry at lines 10490-10496 (identical to lines 10483-10489), which was introduced by the PR's refactoring.

What alternative solutions did you explore? (Optional)

An alternative approach for item 1 would be to keep the PR's conditional but use a different mechanism to prevent avatar flickering — for example, by only clearing the optimistic participant after the BE response has been applied (using a post-success merge instead of a success merge). However, restoring the unconditional cleanup is simpler and proven to work correctly before the regression.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ShridharGoel (External)

[melvin-bot]

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

[arlo-owls]

Proposal

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

App crashes on Android when changing a task assignee to an existing user.

What is the root cause of that problem?

Regression from PR #85539. That PR moved participants: {[assigneeAccountID]: null} cleanup into a conditional that only runs when isOptimisticPersonalDetail(assigneeAccountID) is true (src/libs/ReportUtils.ts:10500).

When reassigning to an existing user you haven't chatted with:

1. Optimistic chat report and personal details are created via setNewOptimisticAssignee
2. getTaskAssigneeChatOnyxData enters the optimistic report block
3. On API success, isOptimisticPersonalDetail() returns false for existing users, so participant cleanup is skipped
4. Stale optimistic participant data persists alongside BE response data

Additionally, failureData at line 10531-10538 unconditionally deletes personal details for the assignee — even real users. If the API fails, this causes null reference crashes in components rendering that user.

There's also a duplicate isOptimisticReport: false success data entry (lines 10483-10489 and 10490-10496).

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

Three changes in getTaskAssigneeChatOnyxData (src/libs/ReportUtils.ts):

1. Restore unconditional participant cleanup on success — move participants: {[assigneeAccountID]: null} back outside the isOptimisticPersonalDetail conditional. Keep personal details deletion conditional (only for optimistic users), but participant cleanup should always run so BE response takes precedence.

2. Guard failure data personal details deletion:

if (isOptimisticPersonalDetail(assigneeAccountID)) {
    failureData.push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: ONYXKEYS.PERSONAL_DETAILS_LIST,
        value: { [assigneeAccountID]: null },
    });
}

3. Remove duplicate isOptimisticReport: false entry (lines 10490-10496).

What alternative solutions did you explore? (Optional)

Post-success merge instead of unconditional cleanup — more complex, less proven. The pre-#85539 approach worked; partial revert is safest.

---

Contributor details
Upwork Profile Link: https://www.upwork.com/freelancers/~0110238ea7fec0963b

[arlo-owls]

Implementation ready at arlo-owls/App@fix/85974-task-assignee-crash. Will submit PR when assigned.

[ShridharGoel]

@lanitochka17 Can you include the crash logs?

[husamdaifalla01-cmyk]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.