You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Duplicate "Beginning of New Chat" Message and Email in LHN when Changing Assignee #24459
Fill in the title, description, and assignee, and share somewhere
Click on the assignee and change it to a new email that has not been used before
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
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:
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:
Clear the optimistic personalDetails when we receive the successDate from onyx in the OpenReport api call here.
In the getOptions function here, exclude duplicate logins giving precedence to the ones that have isOptimisticPersonalDetail set as false.
@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!
Activity
melvin-bot commentedon Aug 11, 2023
Triggered auto assignment to @muttmuure (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.melvin-bot commentedon Aug 11, 2023
Bug0 Triage Checklist (Main S/O)
Platformsin OP are ✅)allroundexperts commentedon Aug 12, 2023
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 returnfalsesince 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:
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
loginkey 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:OpenReportapi call here.getOptionsfunction here, exclude duplicate logins giving precedence to the ones that haveisOptimisticPersonalDetailset asfalse.muttmuure commentedon Aug 14, 2023
Can't currently log into New Expensify
muttmuure commentedon Aug 14, 2023
This seems to be expected behaviour.
allroundexperts commentedon Aug 14, 2023
@muttmuure This is a bug. The issue here is that we're creating duplicate reports.
muttmuure commentedon Aug 14, 2023
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 commentedon Aug 14, 2023
Is the issue that there are two tasks?
muttmuure commentedon Aug 14, 2023
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 commentedon Aug 14, 2023
@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 commentedon Aug 14, 2023
No worries @allroundexperts - definitely always worth double checking.