Duplicate "Beginning of New Chat" Message and Email in LHN when Changing Assignee

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Click the plus sign and select "Assign Task"
2. Fill in the title, description, and assignee, and share somewhere
3. Click on the assignee and change it to a new email that has not been used before
4. Observe that the "Beginning of New Chat" message and email appear twice in LHN.

Expected Result:

The "Beginning of New Chat" message and email should only appear once in LHN when changing the assignee with a new email.

Actual Result:

When changing the assignee to a new email, the "Beginning of New Chat" message and email appear twice in LHN, causing duplication.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.53-1
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

screen-capture.-.2023-08-03T052143.076.mp4

Recording.1167.mp4

Expensify/Expensify Issue URL:
Issue reported by: @tewodrosGirmaA
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1691065190422649

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @muttmuure (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[allroundexperts]

Proposal

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

Duplicate chats being created when editing a task assignee.

What is the root cause of that problem?

The root cause of the issue is that we're having duplicate personal details (one optimistic and other one which was returned from the server) when selecting a new user. When selecting the new task assignee for the second time, the task option selector only shows the optimistically created personalDetail because of this check (The personalDetail that the server sends does not have login attribute set). As such, we're clicking on the personalDetails of the optimistically created user instead of the one returned from the server. This causes ReportUtils.getChatByParticipants([newAssigneeAccountID]) here to return false since the chat report exists for the personal details that was returned from the server. As such, we're re-creating another optimistic chat here which shows up as a duplicate.

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

There are multiple changes that we can do here to fix this. The most straightforward approach is to change the check here to:

        const chat = ReportUtils.getChatByParticipantsByLoginList([assignee]);

This will cause the real chat to always show up, and as such, the duplicated optimistic chat won't be created.

What alternative solutions did you explore? (Optional)

Another option would be to disable the this check but it might cause more regressions.

We can also update the backend so that it returns login key along with each personalDetails object it creates. Doing so will cause duplicate option rows to show up in the TaskAssigneeSelectorModal, but that can be avoided by either of the following:

1. Clear the optimistic personalDetails when we receive the successDate from onyx in the OpenReport api call here.
2. In the getOptions function here, exclude duplicate logins giving precedence to the ones that have isOptimisticPersonalDetail set as false.

[muttmuure]

Can't currently log into New Expensify

[muttmuure]

This seems to be expected behaviour.

[allroundexperts]

@muttmuure This is a bug. The issue here is that we're creating duplicate reports.

[muttmuure]

I only received one "Beginning of New Chat" message. Can you send a screenshot of the duplicate report so I am on the same page?

[muttmuure]

Is the issue that there are two tasks?

[muttmuure]

I switched assignee back and forth from mmoore+2020 to mmoore+2021, and it created a second task. Is that what the issue is referring to?

[allroundexperts]

@muttmuure Sorry for the wrong call here. I just checked this again and it seems to be no longer reproducible. Digging further into the code, it turns out that this was fixed in this PR 3 days ago. We're good to close this!

[muttmuure]

No worries @allroundexperts - definitely always worth double checking.