Workspace - Hmm... it's not here is briefly displayed when downgrading a workspace

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.91-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11/ Chrome, Android 13
App Component: Workspace Settings

Action Performed:

1. Sign in to staging.new.expensify.com with an account with a control workspace
2. Navigate to Workspace > Overview > Plan
3. Downgrade the plan by selecting collect plan

Expected Result:

User is navigated to the overview page

Actual Result:

Hmm.. it's not here is briefly displayed before overview page is displayed

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7169442_1780394525935.bandicam_2026-06-02_12-48-58-336.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7169442

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/1a9c88a22a3ce351abb8fc7de5a6c1780bd037f8ce1f8febef6c213890e6f970

https://platform.applause.com/services/links/v1/external/8743cd2f0724af10f68390d7fff641203a17f2e12a46a05c409e101889015158

[melvin-bot]

Triggered auto assignment to @danieldoglas (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 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]

Issue Analysis

Root cause: Regression from Expensify/App#91305 — "Implement read-only access to workspace pages" (merged to main 2026-06-01). That PR rewired the workspace NotFound gating (auditor / read-access role checks + a new tab-focus gate) across the workspace settings pages. When the Control→Collect downgrade finishes and navigation returns to the workspace Overview, this new gating is re-evaluated for one frame and briefly renders the FullPageNotFoundView ("Hmm... it's not here") before the page settles.

Already fixed (no new code needed): #91305 was reverted in Expensify/App#92342 — "[CP Staging] Revert ..." — merged to staging 2026-06-02 10:22 UTC. That revert explicitly lists this same cluster of NotFound / auditor deploy blockers, including Expensify/App#92336 "Not here page opens when opening workspace settings", which is the same symptom as this issue.

This issue was reported on v9.3.91-0 at 11:57 UTC — ~1.5h after the revert was cherry-picked to staging, so the tester's build predated the fix.

Recommended next step: Re-test on the next staging build that includes #92342 (≥ v9.3.91-1). The flash should be gone. This can be closed as a duplicate of the #91305 revert cluster (same root cause as #92336).

Mechanism & evidence

The downgrade is not the trigger by itself. The optimistic update in downgradeToTeam (Policy.ts:5711) only merges {type: TEAM, isPendingDowngrade: true, isAttendeeTrackingEnabled: null} — it never clears the policy id/role, and none of the access helpers depend on plan type:

• isPolicyAccessible (PolicyUtils.ts:2085)
• canEditWorkspaceSettings (PolicyUtils.ts:1063)
• shouldShowPolicy (PolicyUtils.ts:533)

The flash comes from the read-access gating added by #91305:

• AccessOrNotFoundWrapper.tsx:199 — new canMemberRead(policy, login, policyFeature) read-access check
• AccessOrNotFoundWrapper.tsx:202-207 — isFocused || isWorkspacesTabFocused now drives shouldShowNotFoundPage
• WorkspacePageWithSections.tsx:184-196 — shouldShow (NotFound) gated on isWorkspacesTabFocused

During Navigation.dismissModal() from the downgrade confirmation, the RHP closes and isWorkspacesTabFocused flips back to true, re-running these checks against the just-updated policy and producing a one-frame NotFound before the Overview content renders. This is the same mechanism behind the sibling blockers in the #92342 revert.

Timeline

• 2026-06-01 16:08 UTC — Implement read-only access to workspace pages #91305 merged to main (regressor)
• v9.3.91-0 staging build cut (includes Implement read-only access to workspace pages #91305)
• 2026-06-02 10:22 UTC — [CP Staging] Revert "Implement read-only access to workspace pages" #92342 revert merged (CP Staging)
• 2026-06-02 11:57 UTC — this issue filed on v9.3.91-0 (pre-revert build)

---

Next Steps: This looks already resolved by the #92342 revert — please verify on a staging build that includes it and close as a duplicate of the #91305 cluster if confirmed. Reply with @MelvinBot <feedback> to refine this analysis.

[lakchote]

Not repro on staging:

Screen.Recording.2026-06-02.at.14.57.51.mov

Looks like it was on an anterior version without #92342