Workspace - Infinite loading displayed for second device after delete the Workspace as admin.

[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:

Precognition:
2 accounts are needed for the following tests, 1 Admin and 1 user
With one of the accounts, log in, create a workspace and invite the other account to the workspace.

1. Log in with the same workspace admin account on the main device and the employee in the secondary device/ navigate to #announce room
2. Navigate to a Workspace settings
3. Delete the workspace by click/tap on the 3 dots > Delete workspace
4. Check secondary device

Expected Result:

"Hmm. it's not here . You don't have access to this chat" should be appeared for second device.

Actual Result:

Infinite loading displayed for second device after delete WS as admin.

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.2.94.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/3322739

Email or phone of affected tester (no customers):

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

Notes/Photos/Videos: Any additional supporting documentation

Bug6005687_WS_Kot.mp4

Expensify/Expensify Issue URL:

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.

[MelvinBot]

Triggered auto assignment to @PauloGasparSv (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[kbecciv]

Issue is not reproduced in Production, adding Deploy Blocker Label.

[PauloGasparSv]

Shifting my focus to this!

[PauloGasparSv]

Great! Was able to replicate this in Web : D

Local:

Staging:

[PauloGasparSv]

This may be caused because the report data is still in Onyx after the deletion but the reportActions are removed

Still couldn't figure out which P.R. introduced this but it may be API related

[PauloGasparSv]

For some reason this logic in the API isn't clearing the report_<ReportID> object but instead turning it into this thing

[PauloGasparSv]

Issue is not reproduced in Production, adding Deploy Blocker Label.

Strange thing is that commenting this logic solves the issue! But that logic should be in production, so I'll test production here.

cc @roryabraham if you have any ideas on this as the logic I commented was introduced in this P.R.

After commenting those lines:

[PauloGasparSv]

Also couldn't replicate the issue in production!

The report object still exists in Onyx but has some extra fields, investigating that (specifically why isLoadingReportActions is true is staging and dev but not in prod)

[PauloGasparSv]

All right, I think isLoadingReportActions is being updated wrong now!

Couldn't find any recent changes or the P.R. that introduced this bug yet.

Taking a break for lunch but I'll get back to this ASAP.