[$250] 'It's not here' screen not shown after user is removed from room while in RHP

[lanitochka17]

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: undefined
Reproducible in staging?: Yes
Reproducible in production?: undefined
If this was caught during regression testing, add the test name, ID and link from BrowserStack: undefined
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

Precondition: Have two accounts (User A, User B), opened in two different devices or environments

1. Open the Expensify app (User A)
2. Open or create a private room chat
3. Tap on room header and select 'Members'
4. Invite User B to the room
5. Switch to User B account
6. Open the room and tap on the header
7. While User B remains on RHP, switch to User A account
8. Tap on room header and select 'Members'
9. Remove User B from room chat
10. Switch to User B account

Expected Result:

Removed User should see the "It's not here" screen.

Actual Result:

'It's not here' screen not shown after user is removed from room while in RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7142072_1777561153525.User_A.mp4

Bug7142072_1777561153531.User_B.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059020833197363693
• Upwork Job ID: 2059020833197363693
• Last Price Increase: 2026-05-25

[godzillaxbox19982014-lgtm]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 21:34:39 UTC.

Proposal

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

When User B is removed from a private room while they are still viewing that room's RHP, the RHP keeps rendering stale room UI instead of switching to the "It's not here" / no-access page. I checked the attached videos again: the visible stuck screen is the room Details RHP after the removal.

What is the root cause of that problem?

The room removal update changes the room membership, but the RHP access guard only checks whether the report still exists.

The key path is:

• removeFromRoom() writes the removed account into participants as null in successData, leaving the report object itself in Onyx:

  App/src/libs/actions/Report/index.ts

  Lines 5077 to 5115 in 9498065

  	function removeFromRoom(report: Report, targetAccountIDs: number[]) {
  	const reportID = report.reportID;
  	const reportMetadata = getReportMetadata(reportID);
  	const removeParticipantsData: Record<number, null> = {};
  	for (const accountID of targetAccountIDs) {
  	removeParticipantsData[accountID] = null;
  	}
  	const pendingChatMembers = getPendingChatMembers(targetAccountIDs, reportMetadata?.pendingChatMembers ?? [], CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);
  	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`,
  	value: {
  	pendingChatMembers,
  	},
  	},
  	];
  	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`,
  	value: {
  	pendingChatMembers: reportMetadata?.pendingChatMembers ?? null,
  	},
  	},
  	];
  	// We need to add success data here since in high latency situations,
  	// the OpenRoomMembersPage call has the chance of overwriting the optimistic data we set above.
  	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
  	value: {
  	participants: removeParticipantsData,
  	},

• The room Details / Members / Settings RHP pages are wrapped by withReportOrNotFound().
• withReportOrNotFound() currently decides not-found with !isReportLoaded || !canAccessReport(report, betas, isReportArchived):

  App/src/pages/inbox/report/withReportOrNotFound.tsx

  Lines 101 to 127 in 9498065

  	if (shouldRequireReportID || isReportIdInRoute) {
  	const shouldShowFullScreenLoadingIndicator = !isReportLoaded && (isLoadingReportData !== false || shouldFetchReport);
  	const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);
  	// If the content was shown, but it's not anymore, that means the report was deleted, and we are probably navigating out of this screen.
  	// Return null for this case to avoid rendering FullScreenLoadingIndicator or NotFoundPage when animating transition.
  	if (shouldShowNotFoundPage && contentShown.current && !isFocused) {
  	return null;
  	}
  	if (shouldShowFullScreenLoadingIndicator) {
  	const reasonAttributes: SkeletonSpanReasonAttributes = {
  	context: 'withReportOrNotFound',
  	isLoadingReportData: isLoadingReportData !== false,
  	shouldFetchReport,
  	};
  	return (
  	<FullscreenLoadingIndicator
  	shouldUseGoBackButton
  	reasonAttributes={reasonAttributes}
  	/>
  	);
  	}
  	if (shouldShowNotFoundPage) {
  	return <NotFoundPage isReportRelatedPage />;
  	}

• canAccessReport() only checks default-room beta access and report.errorFields.notFound; it does not check whether the current user is still in report.participants:

  App/src/libs/ReportUtils.ts

  Lines 9079 to 9090 in 9498065

  	function canAccessReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
  	// We hide default rooms (it's basically just domain rooms now) from people who aren't on the defaultRooms beta.
  	if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
  	return false;
  	}
  	if (report?.errorFields?.notFound) {
  	return false;
  	}
  	return true;
  	}

So after User B is removed, the report is still loaded, canAccessReport() still returns true, and the wrapped RHP continues rendering even though User B no longer has access to that private room.

There is already a stricter helper for the access check we need: canCurrentUserOpenReport(), which combines participant/public-room access with the existing canAccessReport() result:

App/src/libs/ReportUtils.ts

Lines 10770 to 10772 in 9498065

	function canCurrentUserOpenReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
	return (isReportParticipant(deprecatedCurrentUserAccountID, report) || isPublicRoom(report)) && canAccessReport(report, betas, isReportArchived);
	}

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

Update withReportOrNotFound() so room-like report RHPs use the participant-aware access predicate:

const shouldUseCurrentUserAccessCheck = isChatRoom(report) || isGroupChat(report);
const canOpenReport = shouldUseCurrentUserAccessCheck
    ? canCurrentUserOpenReport(report, betas, isReportArchived)
    : canAccessReport(report, betas, isReportArchived);
const shouldShowNotFoundPage = !isReportLoaded || !canOpenReport;

That keeps the existing broad canAccessReport() semantics for non-room report pages, while making private rooms and group chats re-evaluate when participants changes. Public rooms still work because canCurrentUserOpenReport() explicitly allows isPublicRoom(report).

I would treat ReportNavigateAwayHandler as only a secondary cleanup here. Adding SCREENS.ROOM_MEMBERS to its RHP allow-list can help some navigation-away cases, but it is not sufficient for this bug because the report is not removed from Onyx, and the expected result is an in-place NotFound page on the visible RHP rather than silently navigating away.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add a focused test for a withReportOrNotFound()-wrapped room RHP:

1. Seed a private room report whose participants includes the current user and assert the wrapped page renders.
2. Merge an update that removes/nulls the current user's participant entry.
3. Assert the wrapped page switches to NotFoundPage.

Also cover a public room where the current user is not in participants, to confirm public-room access still renders normally.

What alternative solutions did you explore? (Optional)

Changing canAccessReport() globally would also make this RHP hide, but it changes the meaning of a shared utility that is used outside route guards. Keeping the participant-aware check in withReportOrNotFound() is more contained.

Patching only RoomMembersPage or only ReportDetailsPage would fix one visible page but leave the same stale-access gap in other report-related RHP screens that share the same wrapper.

[MelvinBot]

Proposal

What is the root cause of that problem?

The reportDetailScreens array in ReportNavigateAwayHandler does not include SCREENS.ROOM_MEMBERS screens. When a user is viewing a room's RHP (e.g. Members page) and gets removed by another user, the navigateAwayFromReport logic hits an early return because isReportDetailOpenInRHP evaluates to false — the current RHP screen isn't recognized as a report-detail screen. This prevents the removed user from being navigated away from the room.

Additionally, the withReportOrNotFound HOC wrapping RHP pages relies on canAccessReport, which only checks errorFields.notFound and default room betas — it does not check whether the current user is still a participant. So even after removal, the report remains "accessible" and NotFoundPage is never shown.

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

Add ...Object.values(SCREENS.ROOM_MEMBERS) to the reportDetailScreens array in ReportNavigateAwayHandler.tsx:30-36. This ensures that when a user is on a Room Members RHP screen and gets removed, the isReportDetailOpenInRHP check passes and navigateAwayFromReport fires correctly instead of hitting the early return.

What alternative solutions did you explore? (Optional)

Considered modifying canAccessReport to also check participant membership (similar to the existing canCurrentUserOpenReport at ReportUtils.ts:10770). However, canAccessReport is used broadly and changing its semantics could have unintended side effects. The reportDetailScreens fix is more targeted and aligns with how other RHP screens (REPORT_DETAILS, REPORT_SETTINGS, REPORT_PARTICIPANTS) are already handled.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

When a user is removed from a room while viewing its RHP (report details, members, or settings screens), the "It's not here" / not-found screen is never shown. The user simply remains on the RHP with no feedback, while the same removal correctly triggers the not-found screen in the main chat view.

What is the root cause of that problem?

The main chat view (ReportScreen) is wrapped in ReportNotFoundGuard, which subscribes to ONYXKEYS.COLLECTION.REPORT and shows FullPageNotFoundView as soon as report?.reportID goes falsy — which happens when the user is removed and the report entry is cleared or the notification preference becomes hidden. RHP screens (ReportDetailsPage, RoomMembersPage, RoomInvitePage, etc.) are instead wrapped in the withReportOrNotFound HOC. That HOC's not-found condition is:

App/src/pages/inbox/report/withReportOrNotFound.tsx

Line 103 in b17de2b

const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);

It calls canAccessReport, which only returns false for default-room beta violations and report.errorFields.notFound. It does not check isHiddenForCurrentUser, so when removal sets notificationPreference to hidden (making isHiddenForCurrentUser return true), canAccessReport still returns true and the HOC happily keeps rendering the RHP screen.

App/src/libs/ReportUtils.ts

Lines 9079 to 9090 in b17de2b

	function canAccessReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
	// We hide default rooms (it's basically just domain rooms now) from people who aren't on the defaultRooms beta.
	if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
	return false;
	}
	if (report?.errorFields?.notFound) {
	return false;
	}
	return true;
	}

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

The cleanest fix is to update canAccessReport in src/libs/ReportUtils.ts to also return false when isHiddenForCurrentUser(report) is true. Since isHiddenForCurrentUser is already defined and exported from the same file, this is a one-line addition before the final return true in canAccessReport. This ensures every caller of canAccessReport — including withReportOrNotFound — automatically handles the removal case. Because withReportOrNotFound is the guard used by all room-related RHP screens (report details, room members, room settings, participant details, private notes, etc.), this single change will fix the not-found behavior across all of them without touching each screen individually.

What alternative solutions did you explore? (Optional)

An alternative is to add the isHiddenForCurrentUser check directly inside withReportOrNotFound's shouldShowNotFoundPage condition rather than in canAccessReport. This is slightly more surgical and avoids any risk of canAccessReport affecting other call sites, but it requires verifying none of those other call sites would be broken by the canAccessReport change — both approaches are safe, but updating canAccessReport is more consistent since the function is explicitly meant to answer "can this user access this report."

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 21:36:56 UTC.

Proposal

Replaces my earlier proposal. I am narrowing the fix from a broad canCurrentUserOpenReport() swap to a private-room membership guard in the shared access check, because restricted workspace rooms are intentionally discoverable/joinable by workspace members before they are participants.

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

When User B is removed from a private room while a report-related RHP is open, the RHP keeps rendering the room UI instead of switching to the "It's not here" / no-access screen.

What is the root cause of that problem?

Report-related RHP pages are guarded by withReportOrNotFound(), which currently shows NotFoundPage only when the report is not loaded or canAccessReport(report, betas, isReportArchived) returns false:

App/src/pages/inbox/report/withReportOrNotFound.tsx

Lines 101 to 127 in b17de2b

	if (shouldRequireReportID || isReportIdInRoute) {
	const shouldShowFullScreenLoadingIndicator = !isReportLoaded && (isLoadingReportData !== false || shouldFetchReport);
	const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);
	// If the content was shown, but it's not anymore, that means the report was deleted, and we are probably navigating out of this screen.
	// Return null for this case to avoid rendering FullScreenLoadingIndicator or NotFoundPage when animating transition.
	if (shouldShowNotFoundPage && contentShown.current && !isFocused) {
	return null;
	}
	if (shouldShowFullScreenLoadingIndicator) {
	const reasonAttributes: SkeletonSpanReasonAttributes = {
	context: 'withReportOrNotFound',
	isLoadingReportData: isLoadingReportData !== false,
	shouldFetchReport,
	};
	return (
	<FullscreenLoadingIndicator
	shouldUseGoBackButton
	reasonAttributes={reasonAttributes}
	/>
	);
	}
	if (shouldShowNotFoundPage) {
	return <NotFoundPage isReportRelatedPage />;
	}

But canAccessReport() only rejects hidden default rooms and reports with errorFields.notFound; it does not check whether the current user still belongs to a private room:

App/src/libs/ReportUtils.ts

Lines 9079 to 9090 in b17de2b

	function canAccessReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
	// We hide default rooms (it's basically just domain rooms now) from people who aren't on the defaultRooms beta.
	if (isDefaultRoom(report) && !canSeeDefaultRoom(report, betas, isReportArchived)) {
	return false;
	}
	if (report?.errorFields?.notFound) {
	return false;
	}
	return true;
	}

When a room member is removed, the client can keep the report object in Onyx while removing that account from report.participants. The room-removal write path shows this state shape by merging the removed account IDs to null under participants, while leaving the report itself intact:

App/src/libs/actions/Report/index.ts

Lines 5107 to 5124 in b17de2b

	// We need to add success data here since in high latency situations,
	// the OpenRoomMembersPage call has the chance of overwriting the optimistic data we set above.
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	participants: removeParticipantsData,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`,
	value: {
	pendingChatMembers: reportMetadata?.pendingChatMembers ?? null,
	},
	},
	];

So for User B, the report can still be "loaded", canAccessReport() still returns true, and every wrapped RHP page continues to render stale private-room content even though User B is no longer a participant.

This is exposed on Android/narrow RHP because ReportNavigateAwayHandler deliberately avoids auto-navigation while a narrow pane modal/RHP is focused:

App/src/pages/inbox/ReportNavigateAwayHandler.tsx

Lines 105 to 108 in b17de2b

	// Early return if the report we're passing isn't in a focused state. We only want to navigate to Concierge if the user leaves the room from another device or gets removed from the room while the report is in a focused state.
	// Prevent auto navigation for report in RHP
	if ((!isFocused && !isHoldScreenOpenInRHP && !isReportDetailOpenInRHP) || (!isHoldScreenOpenInRHP && isInNarrowPaneModal)) {
	return;

The existing participant-aware helper proves the missing access concept already exists:

App/src/libs/ReportUtils.ts

Lines 10752 to 10771 in b17de2b

	function isReportParticipant(accountID: number | undefined, report: OnyxEntry<Report>): boolean {
	if (!accountID) {
	return false;
	}
	const possibleAccountIDs = Object.keys(report?.participants ?? {}).map(Number);
	if (report?.ownerAccountID) {
	possibleAccountIDs.push(report?.ownerAccountID);
	}
	if (report?.managerID) {
	possibleAccountIDs.push(report?.managerID);
	}
	return possibleAccountIDs.includes(accountID);
	}
	/**
	* Check to see if the current user has access to view the report.
	*/
	function canCurrentUserOpenReport(report: OnyxEntry<Report>, betas: OnyxEntry<Beta[]>, isReportArchived = false): boolean {
	return (isReportParticipant(deprecatedCurrentUserAccountID, report) || isPublicRoom(report)) && canAccessReport(report, betas, isReportArchived);

However, using canCurrentUserOpenReport() wholesale in withReportOrNotFound() would be too broad, because restricted workspace rooms are intentionally joinable by workspace members even before they are participants:

App/src/libs/ReportUtils.ts

Lines 11243 to 11252 in b17de2b

	// For restricted visibility rooms, the user must be a workspace member to join
	if (isUserCreatedPolicyRoom(report) && report?.visibility === CONST.REPORT.VISIBILITY.RESTRICTED && !isPolicyMember(policy, deprecatedCurrentUserEmail)) {
	return false;
	}
	if (isReportArchived) {
	return false;
	}
	return isChatThread(report) || isUserCreatedPolicyRoom(report) || isNonAdminOrOwnerOfPolicyExpenseChat(report, policy);

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

Add a targeted membership check for private user-created rooms to canAccessReport().

Concretely, in src/libs/ReportUtils.ts, keep the existing default-room and errorFields.notFound checks, then add a private-room guard along these lines:

const shouldRequireCurrentUserMembership =
    isUserCreatedPolicyRoom(report) &&
    report?.visibility === CONST.REPORT.VISIBILITY.PRIVATE &&
    report?.participants !== undefined;

if (shouldRequireCurrentUserMembership && !isReportParticipant(deprecatedCurrentUserAccountID, report)) {
    return false;
}

That makes the shared report-access predicate return false only when membership is actually required for the report type in this bug: private user-created policy rooms. It should not require membership for restricted rooms, because those remain discoverable/joinable to workspace members, and it should avoid blocking partial reports where participants has not loaded yet.

Since withReportOrNotFound() already calls canAccessReport(), this change makes Report Details, Room Members, Room Invite, Report Settings, Participants, and similar RHP pages render the existing report-related NotFoundPage as soon as the removed user's local participant list no longer includes them.

Also update src/pages/inbox/ReportNotFoundGuard.tsx to include the same access check for the main report screen after loading has completed. Today it only shows not-found for invalid paths or missing reports:

App/src/pages/inbox/ReportNotFoundGuard.tsx

Lines 47 to 54 in b17de2b

	const reportID = report?.reportID;
	const isOptimisticDelete = report?.statusNum === CONST.REPORT.STATUS_NUM.CLOSED;
	const isInvalidReportPath = !!routeParams?.reportID && !isValidReportIDFromPath(routeParams.reportID);
	const isLoading = isLoadingApp !== false || isLoadingReportData || (!isOffline && !!isLoadingInitialReportActions);
	const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;
	const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && !reportExists));

It should subscribe to betas/use the archived state and include a loaded-report access-denied branch, e.g. !!reportExists && !canAccessReport(report, betas, isReportArchived), so dismissing the RHP does not leave the removed user on stale room content in the main report view.

As a defensive follow-up, we can add ...Object.values(SCREENS.ROOM_MEMBERS) to reportDetailScreens in ReportNavigateAwayHandler for wide-layout parity, but that should not be the primary fix. The expected Android behavior is to show the no-access page in the RHP, and the RHP guard/access predicate is the path that can do that reliably.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add focused coverage for:

1. canAccessReport() returns false for a private POLICY_ROOM when the current user's account ID is no longer in report.participants.
2. canAccessReport() still returns true for a restricted user-created policy room without the current user in participants, preserving workspace-member join/discovery behavior.
3. A withReportOrNotFound()-wrapped RHP page switches to NotFoundPage after a private room's participant list loses the current account.
4. ReportNotFoundGuard renders the full-page no-access view for the same private-room no-longer-participant state once report loading is complete.
5. Manual Android regression: User A removes User B from a private room while User B is on the room/header RHP; User B sees "It's not here".

What alternative solutions did you explore? (Optional)

I considered my earlier withReportOrNotFound() change to replace canAccessReport() with canCurrentUserOpenReport(). That catches the removed-participant case, but it is too broad for restricted workspace rooms because non-participants can still be allowed to discover and join those rooms.

I also considered only adding Room Members to ReportNavigateAwayHandler.reportDetailScreens. That helps one navigation edge, but it does not make the active RHP render the expected "It's not here" page, and it does not cover other report-related RHPs that share the same stale canAccessReport() decision.

[melvin-bot]

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

[aswin-s]

Proposal

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

User B has a private room's RHP open (tapping the room header opens Report Details; the same applies to Members/Settings/Participants). User A removes User B from the room. On Android (narrow layout) the RHP keeps rendering the stale room UI and User B never sees the "It's not here" not-found screen.

What is the root cause of that problem?

Every report-related RHP page is wrapped by the shared withReportOrNotFound HOC (confirmed: ReportDetailsPage, RoomMembersPage, RoomMemberDetailsPage, RoomInvitePage, ReportParticipantsPage, ReportSettingsPage, etc. all use it). Its not-found decision is:

// src/pages/inbox/report/withReportOrNotFound.tsx (~line 103)
const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);

canAccessReport (src/libs/ReportUtils.ts:9079-9090) only rejects default-room beta violations and report.errorFields.notFound. It never checks whether the current user is still a participant.

When User B is removed, the report object is not deleted from B's Onyx — only B's membership is revoked (the room-removal path merges the removed account to null in participants: src/libs/actions/Report/index.ts:5077-5142, success data sets participants: {[accountID]: null}). So on B's client isReportLoaded stays true and canAccessReport still returns true → shouldShowNotFoundPage stays false → the RHP keeps rendering stale data.

Why Android-specific: ReportNavigateAwayHandler (the navigate-on-removal logic, mounted on the underlying ReportScreen) early-returns when a narrow-pane modal is open — (!isHoldScreenOpenInRHP && isInNarrowPaneModal) at src/pages/inbox/ReportNavigateAwayHandler.tsx (the guard inside navigateAwayFromReport). On narrow layouts the handler intentionally does nothing while an RHP is open, leaving withReportOrNotFound as the only guard — and it is blind to membership loss. On wide layouts the handler instead navigates away, masking the gap.

Working analog: the main chat (ReportScreen) is wrapped in ReportNotFoundGuard (src/pages/inbox/ReportNotFoundGuard.tsx:29-104), which recomputes shouldShowNotFoundPage reactively from current Onyx state and shows FullPageNotFoundView with subtitleKey="notFound.noAccess". The RHP guard needs the same access-aware re-evaluation.

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

In src/pages/inbox/report/withReportOrNotFound.tsx (~line 103), gate on the current user's access rather than generic report access — use the codebase's existing canonical predicate canCurrentUserOpenReport (src/libs/ReportUtils.ts:10770-10772):

// canCurrentUserOpenReport = (isReportParticipant(currentUser, report) || isPublicRoom(report)) && canAccessReport(...)
const shouldShowNotFoundPage = !isReportLoaded || !canCurrentUserOpenReport(report, betas, isReportArchived);

Because isReportParticipant (ReportUtils.ts:10752-10765) also counts ownerAccountID/managerID, owners and managers retain access; isPublicRoom keeps public rooms viewable for non-members. When B's participants entry becomes null, isReportParticipant returns false, so the shared HOC flips to <NotFoundPage isReportRelatedPage /> for all report-related RHP pages at once — the deepest shared layer, no per-page edits.

Leave loading behavior unchanged (the shouldShowFullScreenLoadingIndicator branch still wins while OpenReport is in flight) and leave canAccessReport untouched so its other callers (reasonForReportToBeInOptionList, etc.) keep their broader semantics.

Tests: seed a private room report that includes the current user, render a withReportOrNotFound-wrapped page, then merge the current user's participants entry to null and assert it switches to NotFoundPage; add a public-room case asserting non-participants still see the page.

What alternative solutions did you explore? (Optional)

• Tightening the !isFocused early-return guard (the posted/first-pass direction): rejected. That guard only matters once shouldShowNotFoundPage is already true, which requires the report to be cleared. Removal does not clear the report (only participants[B] → null), so the guard is never reached, and on the topmost RHP isFocused is true anyway. Fixing it changes nothing for this repro.
• Adding ...Object.values(SCREENS.ROOM_MEMBERS) to reportDetailScreens in ReportNavigateAwayHandler (competitor 1/2): rejected as the fix. The repro RHP is Report Details, already in that allow-list, yet the bug still occurs; and on the affected narrow/Android layout navigateAwayFromReport early-returns via isInNarrowPaneModal before the allow-list is even consulted. That path produces a navigate-away, not the expected "It's not here" screen.
• Adding isHiddenForCurrentUser to canAccessReport (competitor 3): weaker signal. Room removal mutates participants, not notificationPreference, so isHiddenForCurrentUser (ReportUtils.ts:2226-2235) may not fire for this case; and mutating canAccessReport globally risks its other callers. Gating the route guard on participant membership is both more precise and more contained.

[melvin-bot]

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

[lxyct825-ops]

Proposal

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

[$250] 'It's not here' screen not shown after user is removed from room while in RHP

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.