Workspace - No error message and red dot displayed for failed workspace

[kbecciv]

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. Access www.staging.new.expensify.com
2. Sign into applausetester+disabledpolicy@applause.expensifail.com account
3. Disable the internet connection in the device
4. Click/tap on the green plus button (FAB) and create a new Workspace
5. Navigate to Workspace settings
6. Verify the settings are grayed out indicating the workspace is pending to be created
7. Verify the default workspace rooms are created and are visible in LHN
8. Refresh the page or force-kill and relaunch the app
9. Enable the internet connection in the device

Expected Result:

This account has policy creation disabled. When trying to create a policy when offline, the process should fail and an error state should be triggered, in this case the Workspace should not be created and a red dot should appear in the profile icon.

Actual Result:

The workspace isn't created but the user does not receive an error message and no red dot is shown on the profile icon.

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number: 1.2.19.1

Reproducible in staging?: Yes

Reproducible in production?: No

Email or phone of affected tester (no customers):

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

Notes/Photos/Videos: Any additional supporting documentation

Bug5792236_User_does_not_receive_red_dot_icon_for_failed_workspace_creation.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

[kbecciv]

Issue is reproduced in all environment, please attach the link for TR https://expensify.testrail.io/index.php?/tests/view/2900726&group_by=cases:section_id&group_order=asc&group_id=229065

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

[dangrous]

This is pretty likely to be something due to #11439 - looking into it. cc @stitesExpensify and @tylerkaraszewski in case you happen to have any insight.

[dangrous]

Are we missing failureData here: https://github.com/Expensify/App/pull/11439/files#diff-8afe5b71ee0436c21364148c86dadd640f2bff3e3d916addbb1f1f6f7e5b6a43R698 ? That is, if it can't open the report does it just remove everything, rather than displaying it with an error message?

[neil-marcellini]

The reproduction steps are a bit odd to me. If we create a workspace while offline and then kill the app before going back online, will the request still get sent?

[neil-marcellini]

Here's how to disable policy creation. I'm going to try to reproduce this on dev and play around with it.

[dangrous]

@neil-marcellini Now that I can test policy disabled locally, I'm actually not seeing this - however, maybe it's still an issue... It seems like I can still create chats offline and it works fine (so no behavior like is shown in the video, but also no error at all). Let me know what you're seeing on your end!

EDIT - Disregard, I was trying "New Chat" not "New Workspace" - seeing the same as you.

[neil-marcellini]

Oh right the requests are persisted even if you kill the app. It looks like the CreateWorkspace command is returning an error message but it's not in an onyx update format.

We don't set any kind of generic error message in the failure data for creating the workspace here. In fact we actually delete the optimistic policy, which is not desirable if we want to show a RBR leading to the error.

[neil-marcellini]

Why would this not be reproducible on prod? You can have an account with disabled policy creation on prod, and you can sign in and try creating a workspace. I'll see if I can reproduce it on prod now. If so then it's not a deploy blocker. Either way, this is an obscure case that we didn't plan for, so I don't think it should be a blocker.

[neil-marcellini]

Yep I'm able to reproduce on prod, this is not a deploy blocker @kbecciv.

Screen.Recording.2022-10-25.at.5.55.02.PM.mov

[kbecciv]

@neil-marcellini Thank you for double checking the production.
I used the Deploy Blocker label, because two testers are not able to reproduce in production, please attached the evidence

RPReplay_Final1666730805.MP4

.

[dangrous]

This will potentially be fixed by the work done here - https://github.com/Expensify/Web-Expensify/pull/35299 - waiting for that to hit production before investigating further.

[dangrous]

That PR is now on production, haven't had time to see if this still happens yet but hopefully today or tomorrow.

[stitesExpensify]

This is pretty likely to be something due to #11439

I don't think so since that was focused on creating chats, not workspaces (which uses a different API call)

[dangrous]

Yep, I realized after writing that that I think I got my wires crossed. Good to have that confirmed in writing in the history though, thank you!

[dangrous]

So I just tried testing this again - I think I either found another bug, or expanded this one. I am still seeing this particular bug on production, but I also tried creating a workspace while being online, and saw pretty much the same behavior - the chats appear for a split second and then disappear, no RBR or any error shown. Also see a 404 in the console, which is I think trying to get the report that doesn't exist..

@kbecciv do you happen to know what's expected behavior here while online (and if you could confirm what I'm seeing if you have time, that would be great too!)

[neil-marcellini]

I recommend looking at the CreateWorkspace api command in Web-E. Try out the behavior for another type of failure. We need to return the data for this error in the same way as the others, within the onyxData.

[dangrous]

After some further testing, i think this is actually now working as expected (it IS different from the initial videos above) but I'm not sure if "as expected" is ideal. It DOES show an RBR, but it shows up next to the user avatar so it's a bit hard to notice (that's why I missed it). I'm happy to close this for now and revisit later, though, since it might be a larger discussion on where that RBR should go. Unless you disagree!

2022-11-04_16-12-41.mp4

[neil-marcellini]

That looks perfect to me.

[dangrous]

Great! I'll close this then