[$250] Thread - The user remains in the thread conversation after leaving it

[mitarachim]

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.5-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/TR-3122/folder/13177078/41237908/1138023986?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 13 iOS 26.2 Hybrid, Mac 15.4.1 Safari, Chrome
App Component: Chat Report View

Action Performed:

1. Go to https://staging.new.expensify.com
   2.Navigate to a conversation
   3.Start a thread and send some messages
   4.Click on the header of the conversation and hit "Leave thread"

Expected Result:

The user is navigated back to the parent conversation after leaving a thread

Actual Result:

The user remains in the thread conversation after leaving it

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7054354_1768948025167.Recording__1304.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022013838149837532917
• Upwork Job ID: 2013838149837532917
• Last Price Increase: 2026-02-11

Issue Owner

Current Issue Owner: @MarioExpensify

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

[jliexpensify]

I can reproduce this!

[melvin-bot]

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

[melvin-bot]

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

[dmkt9]

Proposal

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

The user remains in the thread conversation after leaving it

What is the root cause of that problem?

1. When we leave the thread, the Navigation.goBack function will be called here to navigate back.
   

   App/src/libs/actions/Report.ts

   Lines 3685 to 3686 in ca68fdc

   	const lastAccessedReportRoute = ROUTES.REPORT_WITH_ID.getRoute(lastAccessedReportID);
   	Navigation.goBack(lastAccessedReportRoute);

2. The goUp function will be used because we pass the backToRoute param.
   

   App/src/libs/Navigation/Navigation.ts

   Lines 405 to 408 in ca68fdc

   	if (backToRoute) {
   	goUp(backToRoute, options);
   	return;
   	}

3. In goUp, we only pop once on the targetState.
   

   App/src/libs/Navigation/Navigation.ts

   Line 365 in ca68fdc

   const {action: minimalAction, targetState} = getMinimalAction(action, rootState);

   
   

   App/src/libs/Navigation/Navigation.ts

   Lines 372 to 373 in ca68fdc

   	const indexOfBackToRoute = targetState.routes.findLastIndex((route) => doesRouteMatchToMinimalActionPayload(route, minimalAction, compareParams));
   	const distanceToPop = targetState.routes.length - indexOfBackToRoute - 1;

   
   

   App/src/libs/Navigation/Navigation.ts

   Line 390 in ca68fdc

   navigationRef.current.dispatch({...StackActions.pop(distanceToPop), target: targetState.key});

However, since we are on RHP, the initial targetState will be rootState, and we will pop back to the ReportsSplitNavigator's state. But we do not continue popping inside ReportsSplitNavigator to the target route, so we end up staying on the last route of ReportsSplitNavigator.

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

Test branch

If the targetState is rootState, then we should recursively call the goUp function to handle the state of the target route.

App/src/libs/Navigation/Navigation.ts

Line 390 in ca68fdc

navigationRef.current.dispatch({...StackActions.pop(distanceToPop), target: targetState.key});

    if (isRootNavigatorState(targetState)) {
        goUp(backToRoute, options);
    }

NOTE: We have several different dispatch actions inside goUp, so we also need to check whether those dispatch actions should trigger recursive calls as described above.

What alternative solutions did you explore? (Optional)

Alternatively, we could use the common pattern in the App, which is to call dismissModal before calling goBack.

App/src/libs/actions/Report.ts

Lines 3685 to 3686 in ca68fdc

	const lastAccessedReportRoute = ROUTES.REPORT_WITH_ID.getRoute(lastAccessedReportID);
	Navigation.goBack(lastAccessedReportRoute);

Navigation.dismissModal();
Navigation.isNavigationReady().then(() => {
    const lastAccessedReportRoute = ROUTES.REPORT_WITH_ID.getRoute(lastAccessedReportID);
    Navigation.goBack(lastAccessedReportRoute);
});

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.
After leaving a thread conversation, the user is not navigated back to the parent conversation and remains in the thread view.

What is the root cause of that problem?
dismissModalWithReport incorrectly assumes the thread is always in a modal (RHP) on wide layouts. On wide layouts, it always calls dismissModal() first, but if the thread is already in ReportsSplitNavigator (not in RHP), dismissing the modal is unnecessary and the subsequent navigation doesn't properly navigate to the parent report, causing the user to remain in the thread view.

When navigating from a thread to its parent report within the same ReportsSplitNavigator, the navigation should update the report route directly without dismissing a modal that doesn't exist.

The earliest incorrect assumption: In dismissModalWithReport at line 642, dismissModal() is always called on wide layouts regardless of whether we're navigating within ReportsSplitNavigator to a different report.

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

• Only dismiss the modal when we are not navigating inside ReportsSplitNavigator.
• If we are moving from one report to another inside ReportsSplitNavigator, use forceReplace: true.
• This avoids dismissing a modal that does not exist.
• Change only dismissModalWithReport in src/libs/Navigation/Navigation.ts.

const dismissModalWithReport = ({reportID, reportActionID, referrer, backTo}: ReportsSplitNavigatorParamList[typeof SCREENS.REPORT], ref = navigationRef) => {
    isNavigationReady().then(() => {
        const topmostReportID = getTopmostReportId();
        const areReportsIDsDefined = !!topmostReportID && !!reportID;
        const isReportsSplitTopmostFullScreen = ref.getRootState().routes.findLast((route) => isFullScreenName(route.name))?.name === NAVIGATORS.REPORTS_SPLIT_NAVIGATOR;

        if (topmostReportID === reportID && areReportsIDsDefined && isReportsSplitTopmostFullScreen) {
            dismissModal();
            return;
        }

        const reportRoute = ROUTES.REPORT_WITH_ID.getRoute(reportID, reportActionID, referrer, backTo);

        if (getIsNarrowLayout()) {
            navigate(reportRoute, {forceReplace: true});
            return;
        }

        if (isReportsSplitTopmostFullScreen && topmostReportID !== reportID) {
            navigate(reportRoute, {forceReplace: true});
            return;
        }

        dismissModal();
        InteractionManager.runAfterInteractions(() => {
            navigate(reportRoute);
        });
    });
};

What alternative solutions did you explore? (Optional)
none

[HiepPP]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-21 06:30:48 UTC.

Proposal

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

When a user leaves a thread conversation by clicking the header and hitting "Leave thread", they remain on the thread screen instead of being navigated away. The expected behavior is to return to the parent conversation.

What is the root cause of that problem?

In src/libs/actions/Report.ts, the leaveRoom function (line 3763) calls navigateToMostRecentReport(report) after leaving a thread. This function finds and navigates to the most recently visited report, not the parent conversation.

For threads, report.parentReportID exists and points to the originating conversation, but the navigation logic doesn't use it. The navigateToMostRecentReport may return the same thread report or another unrelated report, leaving the user stranded on the thread they just left.

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

Modify src/libs/actions/Report.ts in the leaveRoom function.

After line 3868 (the early return for workspace members), add a check for chat threads:

// For chat threads, navigate to the parent conversation instead of the most recent report
if (isChatThread && report.parentReportID) {
    const parentReportRoute = ROUTES.REPORT_WITH_ID.getRoute(report.parentReportID);
    Navigation.goBack(parentReportRoute);
    return;
}

This navigates directly to the parent conversation when leaving a thread, which is the intuitive expected behavior.

No new imports needed - ROUTES, Navigation, and isChatThread are already available in the file.

What alternative solutions did you explore? (Optional)

Considered modifying navigateToMostRecentReport to handle threads specially, but this would add complexity to a general-purpose function. The simpler approach is to handle the thread case explicitly in leaveRoom before calling navigateToMostRecentReport.