[Due for payment 2025-05-27] [$250] Expense - Expense report disappears from LHN after opening transaction thread header in RHP

[mitarachim]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.1.32-0
Reproducible in staging?: Yes
Reproducible in production?: Unable to check
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Mac 15.3 / Chrome
App Component: Other

Action Performed:

Precondition:

• Log in with Expensifail account.

1. Go to staging.new.expensify.com
2. Create a workspace.
3. Go to workspace chat.
4. Submit two expenses to the workspace chat.
5. Click on the expense preview.
6. Click on any expense.
7. Note that the expense report is highlighted in LHN when transaction thread is opened in RHP.
8. Click on the report header.

Expected Result:

The expense report will remain highlighted in LHN after opening report header of the transaction thread.

Actual Result:

The expense report is no longer highlighted and disappears from LHN after opening report header of the transaction thread.
The transaction thread appears in LHN but it is not highlighted.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6811067_1745443626061.20250424_052220.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021915506088661653750
• Upwork Job ID: 1915506088661653750
• Last Price Increase: 2025-04-24
• Automatic offers:
• nkdengineer | Contributor | 107108496

Issue Owner

Current Issue Owner: @CortneyOfstad

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (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.

[melvin-bot]

Triggered auto assignment to @jasperhuangg (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[jasperhuangg]

NAB as this is behind a beta, cc @mountiny since this is related to the better expense view

[nkdengineer]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-29 15:44:38 UTC.

Proposal

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

The expense report is no longer highlighted and disappears from LHN after opening report header of the transaction thread.
The transaction thread appears in LHN but it is not highlighted.

What is the root cause of that problem?

The expense report has hidden notification preference if we only create expense on this report. When we open the report detail page of the transaction thread report, derivedCurrentReportID is changed to a transaction thread report, which causes the expense report to disappear from LHN because it's not the current report now.

App/src/hooks/useSidebarOrderedReportIDs.tsx

Line 66 in e1e89c9

const derivedCurrentReportID = currentReportIDForTests ?? currentReportIDValue?.currentReportIDFromPath ?? currentReportIDValue?.currentReportID;

The problem is lastAccessReportFromPath is changed to transaction thread report when we open the report detail page

App/src/hooks/useCurrentReportID.tsx

Line 24 in e1e89c9

const lastAccessReportFromPath = getReportIDFromLink(lastVisitedPath ?? null);

We already have the logic here to return empty if the route is the sub report page route but it doesn't work as expected

App/src/libs/ReportUtils.ts

Lines 8053 to 8059 in e1e89c9

	function getReportIDFromLink(url: string | null): string {
	const route = getRouteFromLink(url);
	const {reportID, isSubReportPageRoute} = parseReportRouteParams(route);
	if (isSubReportPageRoute) {
	// We allow the Sub-Report deep link routes (settings, details, etc.) to be handled by their respective component pages
	return '';
	}

It is a mistake from this PR, hasRouteReportActionID is checking the pathSegments[2] in the past but we changed it to reportIDSegment then it's always true for the sub report page

App/src/libs/ReportUtils.ts

Lines 8039 to 8040 in e1e89c9

	const reportIDSegment = pathSegments.at(1);
	const hasRouteReportActionID = !Number.isNaN(Number(reportIDSegment));

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

We should update this to the correct check in the past

const hasRouteReportActionID = !Number.isNaN(Number(pathSegments.at(2)));

App/src/libs/ReportUtils.ts

Lines 8039 to 8040 in e1e89c9

	const reportIDSegment = pathSegments.at(1);
	const hasRouteReportActionID = !Number.isNaN(Number(reportIDSegment));

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

Test parseReportRouteParams and verify it works as expected.

What alternative solutions did you explore? (Optional)

Based on the suggestion here, we can refactor parseReportRouteParams like this. Since the focused route of this function is only the report route starting with 'r/', we can keep the first check and change the way to find the reportID param.

function parseReportRouteParams(route: string): ReportRouteParams {
    let parsingRoute = route;
    if (parsingRoute.at(0) === '/') {
        // remove the first slash
        parsingRoute = parsingRoute.slice(1);
    }

    if (!parsingRoute.startsWith(addTrailingForwardSlash(ROUTES.REPORT))) {
        return {reportID: '', isSubReportPageRoute: false};
    }

    const state = getStateFromPath(parsingRoute, linkingConfig.config) as PartialState<NavigationState<RootNavigatorParamList>>;
    const focusedRoute = findFocusedRoute(state);

    const reportID = focusedRoute?.params && 'reportID' in focusedRoute.params ? focusedRoute?.params?.reportID as string : '';

    if (!reportID) {
        return {reportID: '', isSubReportPageRoute: false};
    }

    return {
        reportID,
        isSubReportPageRoute: focusedRoute?.name !== SCREENS.REPORT,
    };
}

#60749 (comment)
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[mountiny]

I think we can handle this one externally

[melvin-bot]

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

[mountiny]

@adamgrzybowski @WojtekBoman could you please help review the proposal from @nkdengineer thanks!

[nkdengineer]

I also have concern about @nkdengineer 's solution. As the method parseReportRouteParams is used in different routes, we shouldn't just hard code to fix the effect for this issue.

@eh2077 It's not a hard code. It's a mistake from this PR that causes the logic doesn't work as expected.

[nkdengineer]

To get params from state, you could:

We can also do that to get the reportID and we can update isSubReportPageRoute logic accordingly.

[mountiny]

@trjExpensify do you think this has to be fixed? It does feel like an edge case to me that might just be adding some unnecessary complexity to code

[trjExpensify]

Eh, I don't love the "active chat" in the LHN bouncing around when you click into details in the RHP.

[shawnborton]

I would love to fix this as well, that feels broken that the highlight get removed just because you go one level deeper in the RHP.

[eh2077]

@nkdengineer 's proposal also looks good to me. The proposed solution is a quick fix which makes sense to me. At the meanwhile, @adamgrzybowski 's suggestion #60749 (comment) will make the code more robust, so it's worth trying, even though it will require more effort.

@mountiny All yours.

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @tgolen, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[tgolen]

I read through the issue, and I agree with using @adamgrzybowski's approach. While I see how @nkdengineer's proposal would fix the problem, I think relying on the position of the parameter in the URL is very brittle. It's exactly that brittleness that lead to this issue in the first place. Rather than repeat that same mistake, having a more robust way of accessing the parameter is preferred.

With that said, I think we need a new full proposal.

[nkdengineer]

@tgolen Updated my alternative solution based on the suggestion here, it's not a complex solution. I tested and it works well. cc @eh2077

[tgolen]

I love that. Thank you! 🟢 for that approach then.

[melvin-bot]

📣 @nkdengineer 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[nkdengineer]

@eh2077 The PR is ready for review.

[CortneyOfstad]

PR is actively being worked on

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.46-12 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: expense report disappears from LHN after opening transaction thread header in RHP #61130

If no regressions arise, payment will be issued on 2025-05-27. 🎊

For reference, here are some details about the assignees on this issue:

• @eh2077 requires payment through NewDot Manual Requests
• @nkdengineer requires payment automatic offer (Contributor)

[melvin-bot]

@eh2077 @CortneyOfstad @eh2077 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]