Workspace - Time page loads infinitely for auditor

[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: 9.3.91-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91305
Email or phone of affected tester (no customers): djoijnsdojsoijnsdoijnsij1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• User A invites User B to workspace as auditor.
• Enable Time and Invoices in workspace settings > More features.
• Perform steps below as auditor (User B).

1. Go to staging.new.expensify.com
2. Go to workspace settings > Time.
3. Go to Invoices.
4. Go to Time.

Expected Result:

Time page will load for auditor.

Actual Result:

Time page loads infinitely for auditor.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169330_1780383942047.4.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7169330

[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/6f1bb6306241bfa59ac26ee421156ac2192f78a89285589355a0b4bffbdc753f

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #91305

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

Proposal

What is the root cause of that problem?

PR #91305 gave auditors read access to workspace feature pages. Before it, an auditor opening Invoices got a Not-Found page, so they never reached it. Now they can — and Invoices is the only one of these pages that opts into the bank-account fetch via shouldSkipVBBACall={false}, which fires openWorkspaceView().

openWorkspaceView() optimistically sets the global reimbursementAccount.isLoading = true. WorkspacePageWithSections derives its spinner from that same global flag (WorkspacePageWithSections.tsx:154), so every workspace page — including Time, which never makes the call itself — shows a spinner while it's true.

For an auditor the flag never flips back to false. OpenWorkspaceView is admin‑gated, so for a non‑admin it returns jsonCode 460 ("admin required"), and OnyxUpdates deliberately skips failureData on 460 (OnyxUpdates.ts:48-56) — so the optimistic isLoading: true is stranded. Returning to Time then spins forever; the WorkspaceSplitNavigator freezes rather than unmounts the Time screen, so its loading state is never reset on the way back.

Confidence: high on the client-side mechanism (which spinner, which global flag, why Time is a passive victim). The 460 is the most likely reason the flag never clears, but I couldn't confirm it without backend/log access. The fix below resolves the issue regardless of the exact reason the flag fails to clear, because it stops auditors from triggering the call at all.

What changes do you think we should make in order to solve the problem?

Don't fire the VBA fetch for read-only members on the Invoices page. canWriteMoreFeatures is already computed there — pass shouldSkipVBBACall={!canWriteMoreFeatures} so auditors skip a call they aren't allowed to make (and don't need, since VBA setup controls are already hidden for them). This restores the pre-PR reality and stops the global loading flag from being toggled by users who can't complete the flow.

Because this is a deploy blocker, reverting #91305 is the fastest safe resolution if a targeted fix can't be tested in time.

What alternative solutions did you explore? (Optional)

• Decouple Time from the shared flag: when shouldSkipVBBACall is true, ignore reimbursementAccount.isLoading in WorkspacePageWithSections. One line, but the global-flag footgun remains for any other page that opts into VBBA.
• Stop the 460 carve-out from stranding boolean loading flags (it exists to avoid undismissable RedBrickRoad errors). Broader and riskier.

Supporting evidence (file:line)

• Invoices opts into the VBA call; Time uses the default skip: WorkspaceInvoicesPage.tsx:43 vs WorkspaceTimeTrackingPage.tsx:39-48
• Spinner derived from the shared global key: WorkspacePageWithSections.tsx:154 and :251
• Optimistic / success / failure all target one global key: BankAccounts.ts:1367-1402
• Key is a single global value, default isLoading: false (why the first Time visit works): CONST/index.ts:7053
• 460 skips failureData, leaving the optimistic flag stuck: OnyxUpdates.ts:48-56
• Time screen is frozen (not remounted) on return, so its firstRender/loading state isn't reset — WorkspaceSplitNavigator uses freezeNonTopScreens: true.

To fully confirm the 460 (couldn't run from here), check a staging log query for OpenWorkspaceView for the affected auditor/policy and inspect response.jsonCode; or look for the client log line [OnyxUpdateManager] Received 460 status code, not applying failure data right after the Invoices visit.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.