[HOLD App#11910] Chat - Two admis and two announce rooms have been created after click Create a Free Policy in OldDot

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

---

Issue found when executing PR #12013

Action Performed:

1. Log in staging.expensify.com
2. Create a new account and validate it
3. After set a Password - Create Control Policy
4. Go to Settings - Policy
5. Select New Policy
6. Select Free Policy
7. Flow will direct you to NewDot
8. Check admin policy

Expected Result:

One admis and One announce rooms have been created after Create a Free Policy

Actual Result:

Two admis and two announce rooms have been created after click Create a Free Policy in OldDot
Also one admin and one announce is showed as Unavailable, but after refresh it shows as normal.

Workaround:

Unknown

Platform:

Where is this issue occurring?

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

Version Number: 1.2.18.4

Reproducible in staging?: Yes

Reproducible in production?: No

Email or phone of affected tester (no customers): any new Control Policy

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

Notes/Photos/Videos: Any additional supporting documentation

Recording.1495.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.

[melvin-bot]

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

[sketchydroide]

@mountiny sorry man, can you check if your PR broke this, QA are saying this was introduced with #12038

[mountiny]

Asked @alex-mechler as this would have to be related to the initial logic change rather than the follow up fix of syntax

[francoisl]

Thanks for reporting @kbecciv. We've been investigating and figured this is not a blocker:

Two admins and two announce rooms have been created after click Create a Free Policy in OldDot

This is now normal, and is related to #12013. The behavior is currently different on production because that PR has not been deployed to production yet.

Also one admin and one announce is showed as Unavailable, but after refresh it shows as normal.

@alex-mechler was able to reproduce this on production, so it doesn't appear to be a regression. We believe it's a bug though, so we'll keep this issue open for further investigation.

[alex-mechler]

I wonder if this is related to #11910 (which has a pr up)

[francoisl]

I'm going to be OOO next and won't have time to look into this one more today, going to put it back in the pool.

[melvin-bot]

Triggered auto assignment to @maddylewis (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[mountiny]

Assigning Autoassigner because bug zero initiative.

I think this was not a bug per se, but we should somehow differentiate between the rooms in LHN.

@alex-mechler Would you be able to provide a summary of the findings from the fireroom? I havent been able to follow the latest there.

[alex-mechler]

Would you be able to provide a summary of the findings from the fireroom? I havent been able to follow the latest there.

• Two admin rooms is not a bug here, as two policies were created. This is normal behavior now that Show Default Rooms when there is a team.expensify.com account on the report #12013 is live, as there is assigned guides in the room.
• Unknown Workspace was reproducible in production, so this was not a blocker. This is unexpected though, and should be fixed. Its possible that Web -OldDot Transition - New workspace is displayed without a name initially #11910 is related, but not confirmed.

[mountiny]

Unknown Workspace was reproducible in production, so this was not a blocker. This is unexpected though, and should be fixed. Its possible that #11910 is related, but not confirmed.

Oh alright so that makes sense, would you be able to update the issue expected and actual results here so we can use this GH for this problem? I think you even got some reproduction steps and screenshots in the Slack

[mountiny]

Lets put this on hold for this #11910 actually as it seems similiar.

[alex-mechler]

If 11910 doesn't solve this, I'll update the OP here!

[maddylewis]

waiting for update on this one - #11910

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[alex-mechler]

I was also not able to reproduce this. It looks like #11910 solved the issue, so I'm going to close this one out