[$250] Not here page appears when assignee leave the task report

[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.4.36-0
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/test-runs/65193884/folder/13177077/43678759/1578901678?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocemate+buzz1889@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: windows 10/chrome
App Component: Other

Action Performed:

Preconditions
User A, User B and User C are members of a group chat.

Steps:

1. Log in as User B and navigate to the group chat
2. Create a new task within the group chat
3. Assign the task to User A
4. As User B leave the group chat
5. As User A go to Reports> Task
6. Open the Task and go to details page> Leave

Expected Result:

Not here error page should not be displayed when assignee leave the group

Actual Result:

Not here error page appears when assignee leave the group

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210896_1784312898472.Recording__1200.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7210896

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078194371865323285
• Upwork Job ID: 2078194371865323285
• Last Price Increase: 2026-07-17

Issue Owner

Current Issue Owner: @Valforte

[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/c54ab6f35cb76ed57863875ec3a0fcb17a7b87a579ddad2a209808a6e2ef9ee6

[MelvinBot]

Proposal

What is the root cause of that problem?

Leaving a task report wipes the report object from Onyx, and the report screen then renders the "Not here" (notFound.noAccess) page.

The "Leave" button calls leaveChat() → leaveRoom() (DynamicReportDetailsPage.tsx:372-380). Inside leaveRoom, the "safe" behavior (only setting notificationPreference: hidden and keeping the report) is gated on isWorkspaceMemberLeavingWorkspaceRoom || isChatThread (Report/index.ts:4907-4949).

A task report is a thread, but isChatThread() requires type === CHAT, and a task's type is TASK, so isChatThread(taskReport) is false (ReportUtils.ts:1844-1846). The task therefore takes the destructive else branch:

• Optimistic: {reportID: null, statusNum: CLOSED, ...}
• Success: Onyx.SET the report to just {reportName}, dropping reportID and statusNum entirely.

The guard then evaluates reportExists = !!reportID || isOptimisticDelete || userLeavingStatus (ReportNotFoundGuard.tsx:53-73). On API success the report has no reportID and no statusNum (so isOptimisticDelete is false), and userLeavingStatus has cleared → all three terms are false → shouldShowNotFoundPage becomes true → "Not here".

(Leaving the group chat as User B is incidental — the same happens whenever a task assignee leaves the task; it just wipes the assignee's own report object.)

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

Treat a task report the same way as a chat thread in leaveRoom so that leaving only hides it (sets notificationPreference: hidden) instead of nulling reportID/statusNum.

Concretely, extend the branch condition in Report/index.ts:4908 (and the matching successData/failureData conditions at :4930) to also cover task reports — e.g. compute const isTaskReport = isTaskReportReportUtils(report); and use isWorkspaceMemberLeavingWorkspaceRoom || isChatThread || isTaskReport. This keeps the report object intact after leaving, so the guard's reportExists check stays true and the user is navigated away cleanly rather than landing on "Not here".

What alternative solutions did you explore? (Optional)

Alternatively, ReportNotFoundGuard could treat a report emptied by a successful leave as "left, not missing", but fixing the destructive branch in leaveRoom is the more targeted change and keeps the leave semantics consistent with chat threads and workspace rooms.

Confidence & evidence

Confidence: High — the code path was traced end to end and each link verified by reading the files at SHA 5ed347bd61d2e69d2fd6405d38c8a88464e4e76b.

Data flow:

1. Task assignee opens the task and taps Leave → leaveChat() → leaveRoom() (task is not a root group chat).
2. isChatThread(task) is false (type === TASK, not CHAT) and it isn't a workspace room → destructive else branch runs.
3. Optimistic write: reportID: null, statusNum: CLOSED. On success: Onyx.SET → {reportName} only.
4. ReportNotFoundGuard: reportExists = !!reportID || (statusNum===CLOSED) || userLeavingStatus → all false after success → shouldShowNotFoundPage true → "Not here" (notFound.noAccess).

If runtime confirmation is desired, look for the [ReportScreen] Displaying NotFound Page log (ReportNotFoundGuard.tsx:79) around the leave time — it logs reportID, isOptimisticDelete, and userLeavingStatus.

Possibly related (different flow, same "Not here" symptom): #96295.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96421) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[aswin-s]

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

When the assignee of a task (User A) opens the task from Reports and taps Leave on the details page, the app briefly shows the "Not here" (FullPageNotFoundView) error page instead of navigating cleanly to a valid chat. This happens on Web (Windows/Chrome) when the task creator (User B) has already left the parent group chat before User A leaves the task thread. The expected result is that leaving the task should dismiss the details modal and land User A on a valid report without the "Not here" screen flashing.

What is the root cause of that problem?

leaveRoom in src/libs/actions/Report/index.ts (lines 4883–5002) is called when User A leaves the task report. The key branch condition inside that function is:

const isChatThread = isChatThreadReportUtils(report);

isChatThread (defined at src/libs/ReportUtils.ts:1844) returns true only when isThread(report) && report?.type === CONST.REPORT.TYPE.CHAT. A task report has type === CONST.REPORT.TYPE.TASK, not CHAT, so isChatThread is false for task reports.

Because isChatThread is false and isWorkspaceMemberLeavingWorkspaceRoom is also false, leaveRoom takes the plain "room deleted" branch for the optimistic update (lines 4906–4915):

// isChatThread=false, so this branch runs:
{
    reportID: null,
    stateNum: CONST.REPORT.STATE_NUM.APPROVED,
    statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
    participants: { [currentUserAccountID]: { notificationPreference: HIDDEN } },
}

Writing reportID: null optimistically to Onyx before navigation completes causes withReportOrNotFound (src/pages/inbox/report/withReportOrNotFound.tsx:116) to immediately re-evaluate its guard. The guard calls canAccessReport (src/libs/ReportUtils.ts:9347), which sees an effectively-null report record and returns false, so the Task details screen renders FullPageNotFoundView ("Not here") while navigateToMostRecentReport (called at line 5001 without first dismissing the modal) is still in flight.

The isWorkspaceMemberLeavingWorkspaceRoom && !isChatThread branch at line 4996 does call Navigation.dismissModal() before navigating away, but task reports never reach it because isWorkspaceMemberLeavingWorkspaceRoom is false. So the RHP stays mounted, re-renders against the now-null report record, and shows the "Not here" page.

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

The minimal correct fix is to treat task reports the same as chat threads in leaveRoom — use MERGE (not null-write) for the optimistic update, and dismiss the RHP before navigating away.

Change 1 — src/libs/actions/Report/index.ts

Extend the isChatThread guard to also cover isTaskReport, so the optimistic Onyx write does not null out reportID:

// around line 4893
import {isChatThread as isChatThreadReportUtils, isTaskReport} from '@libs/ReportUtils';

// ...
const isChatThread = isChatThreadReportUtils(report);
const isTask = isTaskReport(report);   // add this

// line ~4906: change the condition from (isWorkspaceMemberLeavingWorkspaceRoom || isChatThread) to:
isWorkspaceMemberLeavingWorkspaceRoom || isChatThread || isTask
    ? {
          participants: {
              [currentUserAccountID]: {
                  notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
              },
          },
      }
    : { /* existing null-write branch for plain rooms */ }

Apply the same guard update to the successData push and the if (isWorkspaceMemberLeavingWorkspaceRoom || isChatThread) block that follows (around line 4931), so all three data arrays are consistent.

Change 2 — src/libs/actions/Report/index.ts (line 4996–5001)

Add a Navigation.dismissModal() call for task reports before navigateToMostRecentReport, so the RHP unmounts before withReportOrNotFound can re-evaluate against the post-leave Onyx state:

if (isWorkspaceMemberLeavingWorkspaceRoom && !isChatThread) {
    Navigation.dismissModal();
    return;
}

// Add:
if (isTask) {
    Navigation.dismissModal();
    // fall through to navigateToMostRecentReport so User A lands on a valid screen
}

navigateToMostRecentReport(report, conciergeReportID, currentUserAccountID, introSelected, betas);

Why this is the right scope: The root cause is the reportID: null optimistic write that fires before the modal is dismissed. Both changes together — (1) switching the Onyx optimistic update from the null-write branch to the MERGE/HIDDEN branch for task reports, and (2) dismissing the modal before navigation — close the race window that lets withReportOrNotFound render "Not here".

Change 3 (optional hardening) — src/pages/DynamicReportDetailsPage.tsx (around line 372–380)

In the leaveChat handler, call Navigation.dismissModal() explicitly after invoking leaveRoom/leaveGroupChat for task reports, matching the pattern used in the delete-request flow at DynamicReportDetailsPage.tsx:1114-1116 (which wraps the destructive action in TransitionTracker.runAfterTransitions to avoid the "Not Found" flash on slower devices):

// After leaveRoom is called for a task report:
Navigation.dismissModal();

This provides defense-in-depth at the callsite level in addition to the action-level fix in Change 2.

What alternative solutions did you explore? (Optional)

An alternative is to guard canAccessReport (src/libs/ReportUtils.ts:9341) so that a report whose current user has just optimistically set notificationPreference: HIDDEN (leave in flight) does not return false for the still-mounted details page. This would suppress the "Not here" render without touching leaveRoom. However, this approach is fragile — canAccessReport is a broadly used utility and loosening its guard could mask genuine access errors on other report types. The action-level fix (Changes 1 and 2) is narrower and directly addresses the source.

A second alternative is to defer API.write(LEAVE_ROOM, ...) until after the navigation transition completes, using InteractionManager.runAfterInteractions or TransitionTracker.runAfterTransitions. This matches the pattern at DynamicReportDetailsPage.tsx:1114-1116 for delete requests. The downside is that it defers the server call and may cause a brief UI state where the user appears to still be a participant. The dismiss-first approach in Changes 1 and 2 is simpler and keeps the API call timing unchanged.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 19:12:31 UTC.

Proposal

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

When the assignee opens a task from Reports > Tasks and taps Leave on the task's details page, the RHP flips to the "Hmm... it's not here" (Not found) page instead of quietly leaving the task and returning to a valid screen.

What is the root cause of that problem?

A task report is a thread (it has a parentReportID/parentReportActionID), but it is not a chat thread — isChatThread only returns true when type === CONST.REPORT.TYPE.CHAT, and a task's type is TASK.

When Leave is pressed, DynamicReportDetailsPage calls leaveRoom. Its optimistic update branches on isWorkspaceMemberLeavingWorkspaceRoom || isChatThread. Because a task is neither, it falls into the else branch that nulls out the report (reportID: null, statusNum: CLOSED):

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

Lines 4873 to 4896 in c88326a

	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value:
	isWorkspaceMemberLeavingWorkspaceRoom || isChatThread
	? {
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	}
	: {
	reportID: null,
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
	participants: {
	[currentUserAccountID]: {
	notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
	},
	},
	},
	},
	];

The task's details page (DynamicReportDetailsPage) is wrapped in withReportOrNotFound, which decides the report exists purely from !!report?.reportID:

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

Lines 97 to 116 in c88326a

	const isReportLoaded = !isEmptyObject(report) && !!report?.reportID;
	const isReportArchived = useReportIsArchived(report?.reportID);
	// The `isLoadingInitialReportActions` value will become `false` only after the first OpenReport API call is finished (either succeeded or failed)
	const shouldFetchReport = isReportIdInRoute && reportLoadingState?.isLoadingInitialReportActions !== false;
	// When accessing certain report-dependant pages (e.g. Task Title) by deeplink, the OpenReport API is not called,
	// So we need to call OpenReport API here to make sure the report data is loaded if it exists on the Server
	useEffect(() => {
	if (isReportLoaded || !shouldFetchReport) {
	// If the report is not required or is already loaded, we don't need to call the API
	return;
	}
	openReport({reportID, introSelected, betas});
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [shouldFetchReport, isReportLoaded, reportID]);
	if (shouldRequireReportID || isReportIdInRoute) {
	const shouldShowFullScreenLoadingIndicator = !isReportLoaded && (isLoadingReportData !== false || shouldFetchReport);
	const shouldShowNotFoundPage = !isReportLoaded || !canAccessReport(report, betas, isReportArchived);

So the moment leaveRoom merges reportID: null, isReportLoaded becomes false, shouldShowNotFoundPage becomes true, and — since the details RHP is still focused (nothing dismissed it yet: getSearchThreadLeaveRoute also early-returns for a task because it too gates on isChatThreadReportUtils) — the escape hatch at L120 (... && !isFocused) doesn't apply, and NotFoundPage renders in place. This is exactly what the video shows: the URL stays on /search/view/<taskID>/details while the RHP swaps to "it's not here".

Note the main report screen already protects against this same optimistic-null race via a leaving flag, but the details wrapper has no equivalent:

App/src/pages/inbox/ReportNotFoundGuard.tsx

Line 56 in c88326a

const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;

The nulling is also wrong on its own: leaving a task doesn't delete it (it still appears in Reports > Tasks afterward), so it should be hidden, exactly like a chat thread — not treated as a deleted room.

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

Treat task reports the same as chat threads in leaveRoom, so leaving hides the report (sets the assignee's notificationPreference to HIDDEN) instead of nulling it. In src/libs/actions/Report/index.ts, import isTaskReport from ReportUtils and widen the condition:

const isChatThread = isChatThreadReportUtils(report);
const isTaskReport = isTaskReportUtils(report);

value:
    isWorkspaceMemberLeavingWorkspaceRoom || isChatThread || isTaskReport
        ? {
              participants: {
                  [currentUserAccountID]: {
                      notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
                  },
              },
          }
        : {
              reportID: null,
              stateNum: CONST.REPORT.STATE_NUM.APPROVED,
              statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
              participants: { /* ...HIDDEN... */ },
          },

Apply the same || isTaskReport to the matching successData branch a few lines below (the if (isWorkspaceMemberLeavingWorkspaceRoom || isChatThread) check) so the success update also keeps the report and only sets the notification preference.

With this, report.reportID is preserved on leave, isReportLoaded stays true, and the details page never flips to Not found — while navigateToMostRecentReport still moves the user off the task. The task stays consistent with the server state that already keeps it listed in Reports > Tasks.

What specific scenarios should we cover in automated tests to prevent this regression from occurring in the future?

• Unit test for leaveRoom with a task report: assert the optimistic REPORT update sets participants[accountID].notificationPreference = HIDDEN and does not set reportID: null / statusNum: CLOSED (mirroring the existing chat-thread expectation).
• Regression test: after leaveRoom on a task report, withReportOrNotFound's isReportLoaded predicate (!!report?.reportID) stays truthy, i.e. the Not found page is not shown.

What alternative solutions did you explore? (Optional)

Give withReportOrNotFound the same leaving-state escape hatch that ReportNotFoundGuard already has — subscribe to ${ONYXKEYS.COLLECTION.REPORT_USER_IS_LEAVING_ROOM}${reportID} and treat the report as still-present while userLeavingStatus is true. This fixes the flash generically for any report type left with a details page open, but it's a presentation-layer patch that leaves the underlying "a left task gets nulled" inconsistency in place, so I'd prefer the leaveRoom fix as the primary and keep this as a defensive follow-up. A third option — extending getSearchThreadLeaveRoute to dismiss the RHP for task threads — only hides the symptom via navigation timing and still routes to the parent group chat rather than back to the Tasks list.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 19:13:56 UTC.

Proposal

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

The assignee opens the task from Reports > Task, navigates from it to the parent group chat, and taps Leave on the details page. Instead of landing on a valid screen, a full-page "Hmm... it's not here" appears once the leave completes.

What is the root cause of that problem?

The structural cause: the Search branch of leaveGroupChat reveals the screen of the very report that leaving deletes from Onyx. It "preserves" a page that cannot survive the action.

1. The Leave in this repro belongs to the parent group chat, not the task. canLeaveChat has no branch for type: 'task' — every branch requires chat-thread/room/expense-chat/IOU shapes — so a task's details page never renders a Leave item. The expected/actual results in the bug body confirm it: "Not here error page appears when assignee leave the group".
   

   App/src/libs/ReportUtils.ts

   Lines 11575 to 11612 in 5ed347b

   	function canLeaveChat(report: OnyxEntry<Report>, policy: OnyxEntry<Policy>, currentUserAccountID: number | undefined, isReportArchived = false): boolean {
   	if (isRootGroupChat(report, isReportArchived)) {
   	return true;
   	}
   	if (isPolicyExpenseChat(report) && !report?.isOwnPolicyExpenseChat && !isPolicyAdminPolicyUtils(policy)) {
   	return true;
   	}
   	if (isPublicRoom(report) && isAnonymousUserSession()) {
   	return false;
   	}
   	if (isHiddenForCurrentUser(report)) {
   	return false;
   	}
   	// Anyone viewing these chat types is already a participant and therefore cannot leave
   	if (isSelfDM(report)) {
   	return false;
   	}
   	// The user who is a member of the workspace cannot leave the public announce room.
   	if (isPublicAnnounceRoom(report) && !isEmptyObject(policy)) {
   	return false;
   	}
   	if (isInvoiceRoom(report)) {
   	return canLeaveInvoiceRoom(report);
   	}
   	return (
   	(isChatThread(report) && !!getReportNotificationPreference(report)) ||
   	isUserCreatedPolicyRoom(report) ||
   	isNonAdminOrOwnerOfPolicyExpenseChat(report, policy) ||
   	isNonOwnerMangerOfIOUReport(report, currentUserAccountID)
   	);
   	}

2. Because the user arrived via Reports > Task, Search is the topmost fullscreen route, so leaveGroupChat takes its Search branch and calls revealRouteBeforeDismissingModal(getReportRouteForCurrentContext({reportID})) — with the reportID of the group chat being left:
   

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

   Lines 4874 to 4878 in 5ed347b

   	if (isSearchTopmostFullScreenRoute()) {
   	Navigation.revealRouteBeforeDismissingModal(getReportRouteForCurrentContext({reportID}));
   	} else {
   	navigateToMostRecentReport(report, conciergeReportID, currentUserAccountID, introSelected, betas);
   	}

   
   This branch was added in commit f419320e13b (PR #93525, fixing #85560) to keep the user in the Search context instead of redirecting them to Inbox.

3. The reveal inserts SEARCH_REPORT(<left chat>) under the RHP and dismisses the RHP, parking the user on the doomed report's screen:
   

   App/src/libs/Navigation/Navigation.ts

   Lines 1032 to 1052 in 5ed347b

   	function revealRouteBeforeDismissingModal(route: Route, options?: {afterTransition?: () => void}) {
   	if (!canNavigate('revealRouteBeforeDismissingModal', {route}) || !navigationRef.current) {
   	Log.hmmm(`[Navigation] Unable to reveal route before dismissing modal. Can't navigate.`, {route});
   	return;
   	}
   	requestAnimationFrame(() => {
   	navigationRef.current?.dispatch({
   	type: CONST.NAVIGATION.ACTION_TYPE.REPLACE_FULLSCREEN_UNDER_RHP,
   	payload: {route},
   	});
   	// Nested rAF: the first frame commits the route insertion, the second
   	// frame starts the dismiss. This ensures React processes the two dispatches
   	// in separate renders so the dismiss animation is preserved. On narrow,
   	// wait for the hidden destination transition first so the RHP slides out
   	// over the final page instead of briefly revealing the previous page.
   	requestAnimationFrame(() => {
   	dismissModal({afterTransition: options?.afterTransition, waitForTransition: getIsNarrowLayout()});
   	});
   	});
   	}

4. Optimistically the page survives: the merge removes reportID but sets statusNum: CLOSED, and ReportNotFoundGuard counts a CLOSED report as an optimistic delete (reportExists stays true):
   

   App/src/pages/inbox/ReportNotFoundGuard.tsx

   Lines 52 to 56 in 5ed347b

   	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;

5. When LeaveGroupChat succeeds, successData merges null, wiping the whole report by design ("any remaining data is removed upon successful completion"). Now reportExists is false and the guard renders the full-page "Not here":
   

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

   Lines 4856 to 4864 in 5ed347b

   	// Ensure that any remaining data is removed upon successful completion, even if the server sends a report removal response.
   	// This is done to prevent the removal update from lingering in the applyHTTPSOnyxUpdates function.
   	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT>> = [
   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
   	value: null,
   	},
   	];

   
   

   App/src/pages/inbox/ReportNotFoundGuard.tsx

   Line 73 in 5ed347b

   const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && hasSeenLoadingForCurrentReportID && !reportExists));

6. The auto-redirect that normally rescues a wiped report — ReportNavigateAwayHandler, whose removal list already includes isGroupChat(prevReport) — deliberately early-returns for reports inside the right modal navigator (isInNarrowPaneModal), which is exactly where every Search-opened report lives. So no navigation fires and the user is stranded:
   

   App/src/pages/inbox/ReportNavigateAwayHandler.tsx

   Lines 121 to 126 in 5ed347b

   	// 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;
   	}
   	Navigation.dismissModal();

   
   

   App/src/pages/inbox/ReportNavigateAwayHandler.tsx

   Lines 159 to 169 in 5ed347b

   	const isRemovalExpectedForReportType =
   	isEmpty(report) &&
   	(isMoneyRequest(prevReport) ||
   	isMoneyRequestReport(prevReport) ||
   	// Own workspace chats are excluded: a vacation delegate split sends a temporary
   	// Onyx SET that wipes the report — the chat was never intentionally removed.
   	// See issue #84248.
   	(isPolicyExpenseChat(prevReport) && !prevReport?.isOwnPolicyExpenseChat) ||
   	isGroupChat(prevReport) ||
   	isAdminRoom(prevReport) ||
   	isAnnounceRoom(prevReport));

Affected paths: leaveGroupChat has a single call site (DynamicReportDetailsPage.tsx#L372-L380), and this reveal is the only place a to-be-deleted report is re-targeted (getReportRouteForCurrentContext's other consumers navigate to live reports). Wide and narrow layouts both reproduce (SEARCH_REPORT sits in the RightModalNavigator in both); offline, the CLOSED page shows until reconnect, then flips to "Not here" on sync. The task and User B leaving are just how QA reached the Search context — leaving any group chat from Reports > Chats reproduces it.

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

In leaveGroupChat's Search branch, stop revealing the left report and dismiss the modal stack instead (src/libs/actions/Report/index.ts#L4874-L4878):

if (isSearchTopmostFullScreenRoute()) {
    Navigation.dismissModal();
} else {
    navigateToMostRecentReport(report, conciergeReportID, currentUserAccountID, introSelected, betas);
}

The details RHP and the SEARCH_REPORT screen live in the same RightModalNavigator, so one dismissModal() closes both and lands the user on the Search table they came from (Reports > Task here; Spend > Chats in #85560), filters intact. This preserves PR #93525's intent — stay in Search context, never bounce to Inbox — while removing the dependency on a report that is about to cease to exist, online and offline. Regression safety in one sentence: the non-Search path (navigateToMostRecentReport) and leaveRoom/thread flows are untouched, and no other caller uses this reveal.

Why the obvious spot fix fails: adding the task type to ReportNavigateAwayHandler's isRemovalExpectedForReportType (or leaning on that handler at all) cannot work — group chats are already in that list (L167) and the page still strands, because the handler's isInNarrowPaneModal early-return (L121-126) suppresses navigation for every Search-RHP report; and any "leaving the task" diagnosis targets the wrong report, since canLeaveChat never shows Leave for type: 'task'.

What alternative solutions did you explore? (Optional)

1. Set REPORT_USER_IS_LEAVING_ROOM in leaveGroupChat (mirroring leaveRoom's broadcast) so the guard keeps passing — masks the wipe and parks the user indefinitely on a dead report page behind a flag nothing clears in this flow.
2. Keep statusNum: CLOSED in successData so isOptimisticDelete stays true — contradicts the explicit comment that all remaining data must be removed on success (server removal update must not linger) and leaves a ghost chat in Onyx.
3. Revert the branch to navigateToMostRecentReport — fixes the "Not here" but reintroduces #85560 (user yanked out of Search into Inbox), breaking intentional behavior.

[melvin-bot]

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

[melvin-bot]

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

[lorretheboy]

Proposal

What is the root cause of that problem?

When the assignee taps Leave on the task, leaveChat routes to leaveRoom (the task isn't a root group chat):

App/src/pages/DynamicReportDetailsPage.tsx

Lines 372 to 380 in 5ed347b

	const leaveChat = useCallback(() => {
	if (isRootGroupChat) {
	leaveGroupChat(report, quickAction?.chatReportID?.toString() === report.reportID, currentUserPersonalDetails.accountID, conciergeReportID, introSelected, betas);
	return;
	}
	const isWorkspaceMemberLeavingWorkspaceRoom = isWorkspaceMemberLeavingWorkspaceRoomUtil(report, isPolicyEmployee, isPolicyAdmin);
	leaveRoom(report, currentUserPersonalDetails.accountID, conciergeReportID, introSelected, betas, isWorkspaceMemberLeavingWorkspaceRoom);
	}, [isRootGroupChat, isPolicyEmployee, isPolicyAdmin, quickAction?.chatReportID, report, currentUserPersonalDetails.accountID, conciergeReportID, introSelected, betas]);

Inside leaveRoom, the "keep the report, just hide it" path is gated on isChatThread, which is isThread && type === CONST.REPORT.TYPE.CHAT:

App/src/libs/ReportUtils.ts

Lines 1844 to 1846 in 5ed347b

	function isChatThread(report: OnyxInputOrEntry<Report>): report is Thread {
	return isThread(report) && report?.type === CONST.REPORT.TYPE.CHAT;
	}

A task report has type: TASK, not CHAT:

App/src/libs/ReportUtils.ts

Line 8982 in 5ed347b

type: CONST.REPORT.TYPE.TASK,

So isChatThread is false and leaveRoom treats the task like a deletable room. Its successData does an Onyx.SET that reduces the report to just {reportName}, dropping reportID and statusNum:

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

Lines 4942 to 4950 in 5ed347b

	} else {
	// Use the Onyx.set method to remove all other key values except reportName to prevent showing the room name as random numbers after leaving it.
	// See https://github.com/Expensify/App/issues/55676 for more information.
	successData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {reportName: report.reportName},
	});
	}

The same wrong classification makes getSearchThreadLeaveRoute return undefined for the task, so when it was opened from Reports the Search view is never dismissed and the assignee stays on that report:

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

Lines 4786 to 4799 in 5ed347b

	function getSearchThreadLeaveRoute(report: Report, activeRoute: string): Route | undefined {
	if (!isSearchTopmostFullScreenRoute() || !isChatThreadReportUtils(report) || !report.parentReportID || !report.parentReportActionID) {
	return undefined;
	}
	const parentBackTo = getSearchParamFromPath(activeRoute, 'backTo');
	const nestedBackTo = parentBackTo ? getSearchParamFromPath(parentBackTo, 'backTo') : undefined;
	return ROUTES.SEARCH_REPORT.getRoute({
	reportID: report.parentReportID,
	reportActionID: report.parentReportActionID,
	backTo: nestedBackTo ?? parentBackTo ?? undefined,
	});
	}

With the report still mounted and now stripped of reportID/statusNum, ReportNotFoundGuard computes reportExists (!!reportID || isOptimisticDelete || userLeavingStatus) as false and renders the "Not here" page:

App/src/pages/inbox/ReportNotFoundGuard.tsx

Line 56 in 5ed347b

const reportExists = !!reportID || isOptimisticDelete || userLeavingStatus;

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

A task report is a thread and, like a chat thread, leaving it should only hide it for the current user (set notificationPreference: HIDDEN) — not wipe the report. Recognize task reports as thread-like in leaveRoom so it takes the hide branch (both optimisticData and successData) instead of the room-deletion/SET branch:

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

Line 4892 in 5ed347b

const isChatThread = isChatThreadReportUtils(report);

i.e. base the branch on "is this a thread" (chat thread OR task report) rather than isChatThread alone. Apply the same recognition in getSearchThreadLeaveRoute so a task opened from Reports is dismissed correctly on leave:

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

Line 4787 in 5ed347b

if (!isSearchTopmostFullScreenRoute() || !isChatThreadReportUtils(report) || !report.parentReportID || !report.parentReportActionID) {

What alternative solutions did you explore? (Optional)

Harden ReportNotFoundGuard so a report reduced to {reportName} after leaving isn't treated as not-found. This masks the symptom but leaves the incorrect delete-on-leave behavior for tasks, so fixing leaveRoom at the root is preferable.