[Payment due 2025-12-01][$250] Report - Unending skeleton on announce room when owner deletes workspace

[nlemma]

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.2.44-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13177019/test-cases/41237784
Email or phone of affected tester (no customers): expensify416+da2@gmail.com
Issue reported by: Applause Internal Team
Device used: MacOS Chrome, Desktop
App Component: Chat Report View

Action Performed:

1. Owner - Create workspace and invite employee, and 2 other members (a total of 3 members)
2. Employee - Navigate to announce room of the workspace you have been invited too
3. Owner - Delete the workspace

Expected Result:

User should be navigated out of the announce room

Actual Result:

There is unending skeleton in announce room

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6994717_1762336772999.Screen_Recording_2025-11-05_at_12.54.23_in_the_afternoon.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021986202248296840242
• Upwork Job ID: 1986202248296840242
• Last Price Increase: 2025-11-05

Issue Owner

Current Issue Owner: @jliexpensify

[melvin-bot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[TaduJR]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a workspace owner deletes a workspace, employees who are viewing the announce room (#announce) get stuck with an unending skeleton screen instead of being navigated away from the room.

What is the root cause of that problem?

The root cause is in the ReportScreen component's navigation logic that handles report removal. When checking if a report removal should trigger navigation away from the screen, the code checks for various report types but is missing the isAnnounceRoom check.

App/src/pages/home/ReportScreen.tsx

Lines 686 to 687 in 01afb57

	const isRemovalExpectedForReportType =
	isEmpty(report) && (isMoneyRequest(prevReport) || isMoneyRequestReport(prevReport) || isPolicyExpenseChat(prevReport) || isGroupChat(prevReport) || isAdminRoom(prevReport));

The isRemovalExpectedForReportType condition at line 686-687 includes checks for:

• isMoneyRequest(prevReport)
• isMoneyRequestReport(prevReport)
• isPolicyExpenseChat(prevReport)
• isGroupChat(prevReport)
• isAdminRoom(prevReport) ← Admin rooms are included

But it's missing:

• isAnnounceRoom(prevReport) ← Announce rooms are NOT included

When a workspace is deleted:

1. The workspace deletion API call archives all related reports including the announce room
2. The announce room report is removed from Onyx (becomes empty/undefined)
3. The ReportScreen's useEffect at line 675 checks if it should navigate away
4. Since isAnnounceRoom is not in the isRemovalExpectedForReportType check, the condition fails
5. The user stays on the page but the report object is undefined
6. Line 942 shows the skeleton loader when !report is true
7. Result: unending skeleton screen

App/src/pages/home/ReportScreen.tsx

Line 942 in 01afb57

{(!report || shouldWaitForTransactions) && <ReportActionsSkeletonView />}

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

Change 1: Import isAnnounceRoom function

Add isAnnounceRoom to the imports from @libs/ReportUtils:

App/src/pages/home/ReportScreen.tsx

Lines 65 to 86 in 01afb57

	import {
	canEditReportAction,
	canUserPerformWriteAction,
	findLastAccessedReport,
	getParticipantsAccountIDsForDisplay,
	getReportOfflinePendingActionAndErrors,
	getReportTransactions,
	isAdminRoom,
	isChatThread,
	isConciergeChatReport,
	isGroupChat,
	isHiddenForCurrentUser,
	isInvoiceReport,
	isMoneyRequest,
	isMoneyRequestReport,
	isMoneyRequestReportPendingDeletion,
	isOneTransactionThread,
	isPolicyExpenseChat,
	isReportTransactionThread,
	isTaskReport,
	isValidReportIDFromPath,
	} from '@libs/ReportUtils';

import {
    canEditReportAction,
    canUserPerformWriteAction,
    findLastAccessedReport,
    getParticipantsAccountIDsForDisplay,
    getReportOfflinePendingActionAndErrors,
    getReportTransactions,
    isAdminRoom,
    isAnnounceRoom, // ← ADD THIS
    isChatThread,
    isConciergeChatReport,
    isGroupChat,
    isHiddenForCurrentUser,
    isInvoiceReport,
    isMoneyRequest,
    isMoneyRequestReport,
    isMoneyRequestReportPendingDeletion,
    isOneTransactionThread,
    isPolicyExpenseChat,
    isReportTransactionThread,
    isTaskReport,
    isValidReportIDFromPath,
} from '@libs/ReportUtils';

Change 2: Add isAnnounceRoom to the removal check condition

Update the isRemovalExpectedForReportType condition at line 686-687:

App/src/pages/home/ReportScreen.tsx

Lines 686 to 687 in 01afb57

	const isRemovalExpectedForReportType =
	isEmpty(report) && (isMoneyRequest(prevReport) || isMoneyRequestReport(prevReport) || isPolicyExpenseChat(prevReport) || isGroupChat(prevReport) || isAdminRoom(prevReport));

const isRemovalExpectedForReportType =
    isEmpty(report) &&
    (isMoneyRequest(prevReport) ||
     isMoneyRequestReport(prevReport) ||
     isPolicyExpenseChat(prevReport) ||
     isGroupChat(prevReport) ||
     isAdminRoom(prevReport) ||
     isAnnounceRoom(prevReport)); // ← ADD THIS

This ensures that when an announce room is removed (due to workspace deletion), the navigation logic will properly detect it and navigate the user away to Concierge chat or the appropriate screen.

What alternative solutions did you explore?

Alternative 1: Check for POLICY_ANNOUNCE chat type directly

Instead of using isAnnounceRoom, we could check prevReport?.chatType === CONST.REPORT.CHAT_TYPE.POLICY_ANNOUNCE directly in the condition. However, this is not preferred because:

• It's inconsistent with the existing pattern (using helper functions like isAdminRoom, isGroupChat, etc.)
• Less maintainable - if the logic for identifying announce rooms changes, we'd have to update multiple places
• The isAnnounceRoom function already exists and is the standard way to check for announce rooms throughout the codebase

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021986202248296840242

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[IjaazA]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a workspace owner deletes a workspace while an employee is viewing the announce room of that workspace, the employee sees an unending skeleton loader instead of being navigated away from the room. The expected behavior is that the user should be automatically navigated out of the announce room when the workspace is deleted.

What is the root cause of that problem?

The ReportScreen component does not check if the workspace (policy) associated with the report is pending deletion. When a workspace is deleted, the policy's pendingFields.delete field is set, but ReportScreen continues to show the skeleton loader because it's waiting for report data to load. Since the workspace no longer exists, the report data never loads successfully, causing the skeleton loader to display indefinitely.

The screen already handles navigation away when a report is directly removed or when a user leaves a room, but it doesn't check for workspace deletion. This is especially problematic for policy rooms (announce rooms, admin rooms, and policy expense chats) which are tied to the workspace and become invalid when the workspace is deleted.

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

1. Import isPendingDeletePolicy and goBackFromInvalidPolicy from @libs/PolicyUtils to check workspace deletion status and navigate away.

2. Add logic to detect if the current report is a policy room (announce room, admin room, or policy expense chat) by checking isAnnounceRoom(report) || isAdminRoom(report) || isPolicyExpenseChat(report).

3. Track the previous and current policy deletion state using usePrevious hook to detect when the workspace transitions from not-deleted to pending-deletion.

4. Add a useEffect that monitors the policy deletion state. When the workspace becomes pending deletion while the user is viewing a policy room:

   • Check that the screen is focused and the report is a policy room
   • Verify that the policy transitioned from not-pending-delete to pending-delete
   • Navigate the user away using goBackFromInvalidPolicy() which navigates to the workspaces list page

This ensures that when a workspace is deleted, users viewing any policy room are automatically navigated away, preventing the infinite skeleton loader issue.

Pseudo Code:

useEffect(() => {
    // Early return conditions:
    // - Screen not focused
    // - Not a policy room
    // - No policy exists
    // - No previous policy (first render)
    // - Was already pending delete (only trigger on transition)
    // - Is not pending delete (no transition happened)
    if (!isFocused || !isPolicyRoom || !policy?.id || !prevPolicy?.id || prevIsPendingPolicyDelete || !isPendingPolicyDelete) {
        return;
    }
    
    // Workspace just transitioned from not-deleted to pending-delete
    // Navigate user away to workspaces list
    Navigation.isNavigationReady().then(() => {
        goBackFromInvalidPolicy();
    });
}, [isFocused, isPolicyRoom, isPendingPolicyDelete, prevIsPendingPolicyDelete]);

What alternative solutions did you explore? (Optional)

1. Show a "not found" page instead of navigating: We could show a not found page when the policy is deleted, but this doesn't match the expected behavior of navigating away. The user should be taken back to a valid screen (workspaces list).

2. Check in the skeleton loading logic: We could modify the skeleton loading condition to check for policy deletion, but this would still leave the user on an invalid screen. Navigation is the better UX.

[mananjadhav]

Will review the issue and proposals by tomorrow.