Workspace - New users invited to WS are not displayed in members list but chats are created for them

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open staging.new.expensify.com
2. Go to to Workspace > Members
3. Invite a new user to workspace

Expected Result:

Newly invited users are present in the Members list immediately after being invited.
Chats in LHN for new users are created.

Actual Result:

New users are not displayed in the members list after being invited. The workspace chat is displayed in LHN immediately but the user is not displayed in members list right away. If the user navigates back to Workspace settings, a red dot can be seen here:

This red dot is removed after the user is finally displayed in the members list.

Workaround:

Unknown

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

Reproducible in staging?: Yes
Reproducible in production?: No

If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/3498653

Email or phone of affected tester (no customers):

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Bug6096645_Web-WS-gmail-members-list.mp4

Expensify/Expensify Issue URL:
po
Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

[OSBotify]

👋 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 @PauloGasparSv (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[PauloGasparSv]

Taking a look at this in a bit

[isagoico]

@PauloGasparSv I think the issue is that there's a huge delay on members being displayed on the members list after a user without an existing account is invited. Going to edit the OC a bit as I'm able to reproduce with both public and domain controlled accounts.

[PauloGasparSv]

@PauloGasparSv I think the issue is that there's a huge delay on members being displayed on the members list after a user without an existing account is invited. Going to edit the OC a bit as I'm able to reproduce with both public and domain controlled accounts.

Makes sense, I could only replicate this by inviting a non-existing account. I think this problem is known, will test production and investigate!

I think this is caused because of AddMembersToWorkspace failing

[PauloGasparSv]

Btw, when I replicate this in staging there is 1 difference: The non-existing account I invited is added to the workspace member list.

Other than that everything is the same, the chat is created first then the user shows in the list a bit later + there is an error indicator in the workspace members page.

Logs

[PauloGasparSv]

Still not sure but this may be related to #20211 and the changes in #20482 and #20397

still investigating

[PauloGasparSv]

Oh ok, maybe this is causing the error

The type field is being sent as receiptUpload (mapped here) when I invite people to the Workspace. I think maybe this line is not returning an accountID and this logic is not populating that because of the receiptUpload type.

Locally, that type is sent as chat when I invite a new user

Since I can't replicate in prod or locally I'm comparing what the logic does in these diff environments.

[PauloGasparSv]

Looked a bit more at the logic and I actually think it's ok for the type to be that, that type chat was being called specifically for concierge and not the new user! Sorry for the confusion.

Looks like the account wasn't created in time to add it to the workspace. I'm investigating where the account creation happens in that request.

[PauloGasparSv]

Hid the above comment by mistake!

I think I'm getting stuck here but while I was testing the problem stopped happening on staging web:

Screen.Recording.2023-06-19.at.16.04.57.mov

I can see no errors or RBR now and the user is added to the members list correctly! This may have been fixed by somethig that was CP'd so I'll check for that.
There is one problem left thought, the member is only added after the request finishes running. I don't think that's worth a blocker thought but we can continue investigating that here.

In the meantime, @kbecciv could you please re-test this and check if it still happens to you?

[PauloGasparSv]

Carlos was able to replicate this on staging.

I had another successfull test in staging Web thought so I'm pretty confused.

[chiragsalian]

Not a blocker, looks like optimistic and failure data are just not being set properly for this flow. This shouldn't block us from deploy.

[PauloGasparSv]

I'll work on this during the week and add that optimistic data, changing this to a daily.

[PauloGasparSv]

Ok, I think I found where the optimisticData is not set here. This only happens to new users, I think it's because we don't know the correct accountID for that user + don't have their info in addMembersToWorkspace.

Still need some more time on this, will work on it later down the week.

[PauloGasparSv]

No updates here today, will get back to this asap

Also changing the priority here to weekly since it's a pretty minor bug and fix.

[PauloGasparSv]

Ok, I think I found where the optimisticData is not set here. This only happens to new users, I think it's because we don't know the correct accountID for that user + don't have their info in addMembersToWorkspace.

Back to this!

No idea how to deal with this error, will double-check if that is the case. I also need to test what happens if you are offline and do this

[PauloGasparSv]

Investigated this further today!

I still can't replicate this locally but it still happens in staging if:

1. You open the Workspace members list
2. Go offline
3. Invite a non-existing account
4. Go back online

Logs for that attempt indicate that:

1. This empty isClosed check in Web-E was successful and the error is coming from the AuthTokenManager::getEmailToken
2. We have 2 instances of request authtoken type= in those logs, first using type=chat then type= receiptUpload when it breaks
3. This may have to do with the isClosed check in Web-E or Auth

Still need to investigate this further!

[Christinadobrzyn]

Hi @PauloGasparSv - do you think this is related to this issue? seems similar but not 100% sure?

[PauloGasparSv]

Hi @PauloGasparSv - do you think #22359 is related to this issue? seems similar but not 100% sure?

Will get back to you on that ASAP (will try doing so on Monday)

[PauloGasparSv]

Hi @PauloGasparSv - do you think #22359 is related to this issue? seems similar but not 100% sure?

Hey @Christinadobrzyn just checked and replicated #22359 and it really isn't related to this!

I can see no errors or RBR now and the user is added to the members list correctly! This may have been fixed by somethig that was CP'd so I'll check for that.

Part of the issue here was pretty similar but then it stopped happening. What I was investigating was the cause of the error thought and not the RBR not clearing

There is one problem left thought, the member is only added after the request finishes running. I don't think that's worth a blocker thought but we can continue investigating that here.

Now I'm focused at this!

[PauloGasparSv]

Hey @Christinadobrzyn I'm going OOO for 2 weeks (starting on July 17th, back on July 31st) so I won't be updating this issue until then.

Please feel free to re-assign this to another engineer!

[PauloGasparSv]

I'm back from OOO, will pick this back up ASAP

[PauloGasparSv]

Picked this back up right now!

I can't reproduce this locally or in staging anymore (tested on Web chrome and Safari desktop) so I believe we fixed this in another P.R. these past few weeks.

Closing this!