[$250] Clicking "View Details" on an expense/report shows the "Hmm... it's not here" page

[MelvinBot]

Bug Description

Clicking View Details from the expense/report actions menu renders the "Hmm... it's not here" (Not Found) page instead of opening the expected details page.

Steps to Reproduce

1. Open a report or expense in New Expensify (web).
2. Open the expense/report actions menu.
3. Select View Details.

Expected Result

The relevant details page/panel for the selected expense or report should open, allowing the user to view the information normally.

Actual Result

The "Hmm... it's not here" page is rendered, preventing the user from viewing the details.

Platform

Web (NewDot)

Slack thread: https://expensify.slack.com/archives/C049HHMV9SM/p1778011018337669

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051945719176094675
• Upwork Job ID: 2051945719176094675
• Last Price Increase: 2026-05-06

[melvin-bot]

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

[melvin-bot]

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

[Ltbltbltbltb]

Proposal

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

Clicking View Details from an expense/report actions menu opens a Not Found page instead of the valid details view.

What is the root cause of that problem?

The same action key is used for report-level and transaction-level View Details: src/CONST/index.ts#L1332 and src/CONST/index.ts#L1386. The handlers currently call navigateToDetailsPage() with the money request / expense report object in both flows. That helper builds a report-details route, but expense reports do not have the normal chat/report details page, so navigation lands on the “Hmm... it’s not here” screen.

This affects both code paths that expose the menu: the report header View Details implementation and the transaction/expense header View Details implementation.

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

Keep the fix at the menu handler level: when View Details is selected for a money request / expense report, navigate using the parent chat report that owns the details panel, not the money request report itself. For the single-transaction expense menu, use the same rule so both entry points are covered.

[CONST.REPORT.SECONDARY_ACTIONS.VIEW_DETAILS]: {
    value: CONST.REPORT.SECONDARY_ACTIONS.VIEW_DETAILS,
    text: translate('iou.viewDetails'),
    icon: expensifyIcons.Info,
    sentryLabel: CONST.SENTRY_LABEL.MORE_MENU.VIEW_DETAILS,
    onSelected: () => {
        navigateToDetailsPage(chatReport ?? moneyRequestReport, Navigation.getReportRHPActiveRoute());
    },
},

[CONST.REPORT.TRANSACTION_SECONDARY_ACTIONS.VIEW_DETAILS]: {
    value: CONST.REPORT.SECONDARY_ACTIONS.VIEW_DETAILS,
    text: translate('iou.viewDetails'),
    icon: expensifyIcons.Info,
    onSelected: () => {
        navigateToDetailsPage(parentReport ?? report, Navigation.getActiveRoute());
    },
},

This is the narrowest fix: it preserves the existing VIEW_DETAILS actions from src/CONST/index.ts#L1332 / src/CONST/index.ts#L1386, reuses navigateToDetailsPage(), and only corrects which report object is passed from the two visible menu entry points.

Contributor Details

Field	Value
Contributor email	lucastrba@gmail.com
Upwork Profile	https://www.upwork.com/freelancers/~01d016059c6701ebaa

[aswin-s]

Proposal

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

When a user deletes an expense or transaction from the details page on web, the app navigates to the target report but briefly renders the "Hmm... it's not here" (NotFoundPage) before the correct details page appears. This race condition occurs because the URL guard that suppresses the NotFoundPage is being cleared at the wrong time—on the source screen as it loses focus—rather than on the destination screen after it gains focus, causing the guard to become null before the destination screen's data stabilizes.

What is the root cause of that problem?

The bug originates in src/pages/inbox/DeleteTransactionNavigateBackHandler.tsx at lines 19–20. A regression from PR #83613 inverted the isFocused guard from !isFocused to isFocused, inverting the intended behavior.

The causal chain: When deleting a transaction, the source ReportScreen calls clearDeleteTransactionNavigateBackUrl() wrapped in InteractionManager.runAfterInteractions(). With the inverted guard (isFocused), this clear now fires when the source screen loses focus (navigating away). Meanwhile, the destination ReportDetailsPage defers its deleteTransaction() call with another InteractionManager.runAfterInteractions() (line 1064). The destination's ReportNotFoundGuard (line 53 of ReportNotFoundGuard.tsx) uses !deleteTransactionNavigateBackUrl as its suppression guard:

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

If the source's clear races ahead before the destination's Onyx writes propagate, the URL becomes null, the report thread no longer exists (deleted), and shouldShowNotFoundPage becomes true, briefly rendering the NotFoundPage.

The working analog is ReportNotFoundGuard.tsx (lines 53–64), which expects the URL to remain non-null as a suppression guard until the destination screen stabilizes.

App/src/pages/inbox/ReportNotFoundGuard.tsx

Lines 53 to 64 in cab0b7b

	const shouldShowNotFoundPage = !deleteTransactionNavigateBackUrl && (isInvalidReportPath || (!isLoading && !reportExists));
	useEffect(() => {
	if (!shouldShowNotFoundPage) {
	return;
	}
	Log.info('[ReportScreen] Displaying NotFound Page', false, {
	isLoadingApp,
	isLoadingReportData,
	isOffline,
	isLoadingInitialReportActions,
	reportID,

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

1. File: src/pages/inbox/DeleteTransactionNavigateBackHandler.tsx
   Function: DeleteTransactionNavigateBackHandler
   Edit: Revert the isFocused guard at line 20 from if (isFocused || ...) back to if (!isFocused || ...). This restores the pre-regression behavior where clearDeleteTransactionNavigateBackUrl() fires only after the destination screen gains focus, ensuring the ReportNotFoundGuard suppression remains non-null until Onyx writes stabilize.

Blast radius: Isolated to DeleteTransactionNavigateBackHandler—a single-character guard inversion with no shared helpers modified. The component is mounted only inside ReportScreen, with no callers passing props into the guard logic.

What alternative solutions did you explore? (Optional)

Moving clearDeleteTransactionNavigateBackUrl() into the deleteTransaction() callback in ReportDetailsPage.tsx (lines 1060–1067) was rejected because it couples clearing to a single call-site and silently breaks any other code path that sets the NVP without going through ReportDetailsPage's navigateToTargetUrl. It also removes the architectural purpose of DeleteTransactionNavigateBackHandler as the canonical clear-on-focus owner.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

I traced this back to the recent migration in aaed2e394c1 ("Migrate all reportMetadata readers to reportLoadingState/reportLastVisitTimes") which changed src/pages/inbox/report/withReportOrNotFound.tsx#L78-L87 to read isLoadingInitialReportActions from RAM_ONLY_REPORT_LOADING_STATE (the new RAM-only key) instead of REPORT_METADATA (a persisted key).

When the user clicks View Details from MoneyReportHeaderSecondaryActions (src/components/MoneyReportHeaderActions/MoneyReportHeaderSecondaryActions.tsx#L342-L344) or MoneyRequestHeaderSecondaryActions (src/components/MoneyRequestHeaderSecondaryActions.tsx#L399-L401), navigateToDetailsPage() pushes r/<reportID>/details and withReportOrNotFound mounts. There it evaluates:

const shouldFetchReport = isReportIdInRoute && reportLoadingState?.isLoadingInitialReportActions !== false;

Because RAM_ONLY_REPORT_LOADING_STATE is registered as RAM-only in src/setup/index.ts#L60-L73 and the report we are already viewing has isLoadingInitialReportActions: false in it (set by the prior openReport success in src/libs/actions/Report/index.ts#L1399-L1407), the first render of the new screen sees:

• reportLoadingState?.isLoadingInitialReportActions === false → shouldFetchReport = false,
• report from useOnyx is still undefined for one tick → isReportLoaded = false,
• isLoadingReportData !== false is also false,

so withReportOrNotFound.tsx#L101-L122 skips the loading indicator and renders NotFoundPage — the "Hmm… it's not here" screen — until report resolves on a later render. The same stale-flag race is already documented in src/pages/inbox/LinkedActionNotFoundGuard.tsx#L88-L93:

// For previously loaded reports, stale metadata may already have isLoadingInitialReportActions: false

LinkedActionNotFoundGuard defends against it with hasSeenLoadingCycle; withReportOrNotFound does not, which is why View Details now renders NotFoundPage on web after the migration.

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

I'd suppress NotFoundPage until we've actually observed at least one mount tick where the report subscription has settled — i.e., don't conclude "not found" while report is still undefined from useOnyx. The cleanest way is to require BOTH isLoadingReportData === false AND a settled report value (not just truthiness of the report object):

-const isReportLoaded = !isEmptyObject(report) && !!report?.reportID;
+const isReportSettled = report !== undefined; // useOnyx returns undefined until first read resolves
+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;

-if (shouldShowFullScreenLoadingIndicator) {
+if (shouldShowFullScreenLoadingIndicator || !isReportSettled) {
     const reasonAttributes: SkeletonSpanReasonAttributes = {
         context: 'withReportOrNotFound',
         isLoadingReportData: isLoadingReportData !== false,
         shouldFetchReport,
     };
     return <FullscreenLoadingIndicator reasonAttributes={reasonAttributes} />;
 }

This preserves the legitimate "report truly missing" path: once report has been read (even if it's an empty object), isReportSettled is true and shouldShowNotFoundPage evaluates as before. It only blocks the false-positive flash where the RAM-only loading flag has resolved synchronously while the persisted report collection key hasn't yet — exactly the new condition the migration introduced.

What alternative solutions did you explore? (Optional)

• Mirroring LinkedActionNotFoundGuard's hasSeenLoadingCycle (require we've seen isLoadingInitialReportActions === true at least once before trusting false). This works but adds state and only helps reports that we re-openReport; reports we already loaded earlier this session never re-enter the loading cycle, so the stale-false race still slips through on the very first tick.
• Forcing openReport unconditionally on mount inside withReportOrNotFound. Rejected — re-fetches on every details navigation are wasteful and would mask the underlying timing issue rather than fix it.
• Reverting withReportOrNotFound to read reportMetadata?.isLoadingInitialReportActions. Rejected — that key is no longer being written after e34ca74f0dd, so the condition would always evaluate to true and we'd refetch every time.

[15antonian]

Proposal

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

On web (NewDot), clicking View Details from the expense or report actions menu renders the "Hmm... it's not here" not-found page instead of opening the expected report details panel. This happens when the user is viewing an expense or report through the wide RHP (the e/:reportID or search/money-request-report routes that mount as super-wide right-panel views).

What is the root cause of that problem?

The failure originates in navigateToDetailsPage in src/libs/ReportUtils.ts:6131, which calls Navigation.navigate(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(...)) unconditionally:

if (report?.reportID) {
    Navigation.navigate(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(report?.reportID, backTo));
}

When the user is inside EXPENSE_REPORT or SEARCH_MONEY_REQUEST_REPORT (the super-wide RHP screens registered at linkingConfig/config.ts:2139), Navigation.navigate calls linkTo, which calls getMinimalAction. That function drills into the current state by matching navigator names top-down. It matches RIGHT_MODAL_NAVIGATOR and descends into the super-wide RHP's inner state — which contains only EXPENSE_REPORT (a single screen at e/:reportID). The resulting minimal action targets that inner state key with payload.name = REPORT_DETAILS. However, EXPENSE_REPORT is a leaf screen — it has no REPORT_DETAILS child. The standard StackRouter cannot resolve this action, so the push silently fails or produces an unroutable path that hits the SCREENS.NOT_FOUND: '*' wildcard route, rendering the not-found page.

The condition isNavigatingToModalFromModal in RootStackRouter.ts:124 — which would correctly handle modal-to-modal transitions — is never reached because getMinimalAction strips the RIGHT_MODAL_NAVIGATOR wrapper from the action before the router sees it.

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

In navigateToDetailsPage in src/libs/ReportUtils.ts, check Navigation.getReportRHPActiveRoute() before navigating. That function returns a non-empty string only when the user is inside a super-wide RHP (EXPENSE_REPORT or SEARCH_MONEY_REQUEST_REPORT). When that condition is true, use Navigation.dismissModal({afterTransition: () => Navigation.navigate(...)}) instead of a direct navigate. This pattern — already used widely for modal-then-navigate flows in WorkspaceInviteMessageComponent.tsx and elsewhere — ensures the super-wide RHP is fully dismissed before linkTo runs, so getMinimalAction operates on a navigation state that no longer has a locked-in RHP inner key, and REPORT_DETAILS can be pushed onto a fresh RIGHT_MODAL_NAVIGATOR stack without being swallowed. When not in a super-wide RHP, the existing direct navigate path is preserved.

Compare branch: https://github.com/Expensify/App/compare/main...15antonian:App:fix/89724-view-details-rhp-context?expand=1

What alternative solutions did you explore? (Optional)

Option: Change isNavigatingToModalFromModal in RootStackRouter.ts to detect super-wide RHP screens (EXPENSE_REPORT, SEARCH_MONEY_REQUEST_REPORT) and route them through handleNavigatingToModalFromModal. Rejected because that handler replaces the current modal rather than stacking a new one, which would close the expense view before the details panel appears — losing the user's place. It also widens the scope of a navigation primitive that has historically caused state corruption when applied too broadly.

Option: Modify getMinimalAction to detect when the inner target state has no matching screen and fall back to targeting the root state. Rejected because getMinimalAction is a low-level helper used across all navigation flows; changes there risk unintended regressions in other RHP and split-navigator transitions.

Option: Pass a new forceRootNavigator flag to Navigation.navigate to skip getMinimalAction entirely for this call. Rejected because the fix would need threading through multiple layers (navigate → linkTo → getMinimalAction) and adds API surface for a problem that is more cleanly solved at the call site.

Compare branch: https://github.com/Expensify/App/compare/main...15antonian:App:fix/89724-view-details-rhp-context?expand=1

[MelvinBot]

Proposal

What is the root cause of that problem?

The "View Details" action in MoneyReportHeaderSecondaryActions.tsx:341-343 and MoneyRequestHeaderSecondaryActions.tsx:399-401 navigates to r/{reportID}/details, which renders ReportDetailsPage wrapped in withReportOrNotFound.

The HOC shows NotFoundPage when canAccessReport returns false (line 103). canAccessReport rejects reports that have errorFields.notFound set.

The problem is an inconsistency between guards: the report screens that show the report (SearchMoneyRequestReportPage at line 300-331 and ReportNotFoundGuard) do not check errorFields.notFound, while withReportOrNotFound does. So a report with a stale notFound error is visible in the report view, but clicking "View Details" shows the Not Found page.

Compounding this, withReportOrNotFound's openReport effect (line 91-99) skips calling openReport when isReportLoaded is true. Since the report data exists in Onyx (the user was just viewing it), the stale errorFields.notFound is never cleared by a fresh openReport success response.

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

Two complementary fixes:

1. In withReportOrNotFound: When isReportLoaded is true but canAccessReport fails due to errorFields.notFound, call openReport to refresh the report data instead of immediately showing NotFoundPage. This gives the server a chance to clear the stale error.

2. In canAccessReport or withReportOrNotFound: Consider clearing errorFields.notFound from the report when the report has valid data (has a reportID, is not empty). If the report data exists in Onyx with real content, a stale notFound error from a prior failed API call should not permanently block access to details.

The fix in option 1 is more conservative — it retries the API call before giving up. The fix in option 2 directly addresses the stale state.

What alternative solutions did you explore? (Optional)

• Aligning SearchMoneyRequestReportPage and ReportNotFoundGuard to also check errorFields.notFound was considered, but this would make the report inaccessible everywhere rather than fixing the inconsistency.
• Modifying the openReport failure data to explicitly clear errorFields.notFound was considered, but the failure data shouldn't make assumptions about prior state.

Investigation details

Navigation flow:

1. User sees report → clicks three-dot menu → "View Details"
2. navigateToDetailsPage navigates to r/{reportID}/details (ReportUtils.ts:6131-6132)
3. withReportOrNotFound reads report from Onyx, checks canAccessReport
4. If errorFields.notFound is truthy → canAccessReport returns false → NotFoundPage shown

Guard inconsistency:

• SearchMoneyRequestReportPage checks: invalid reportID, pending deletion, deleted transactions, deleted parent action — no errorFields.notFound check
• ReportNotFoundGuard checks: invalid path, loading state, report existence — no errorFields.notFound check
• withReportOrNotFound (wrapping ReportDetailsPage) checks canAccessReport which explicitly checks errorFields.notFound

Stale error persistence:

• openReport success data clears notFound: { errorFields: { notFound: null } }
• But withReportOrNotFound skips openReport when report is already loaded (line 92)
• So the stale notFound error is never cleared

Recent migration (commit aaed2e394c1):

• Changed shouldFetchReport from using persisted reportMetadata to RAM-only reportLoadingState
• When reportLoadingState is undefined (RAM cleared), shouldFetchReport becomes true
• This actually helps: it would trigger a loading indicator and openReport call if the report weren't loaded
• However, since the report IS loaded (just has stale notFound), this doesn't help

---

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.

[trasnake87]

Proposal

Clicking View details from the secondary-action ("More") menu on an expense/report navigates to a route the destination cannot resolve, so withReportOrNotFound falls through to the "Hmm... it's not here" page.

Root cause

navigateToDetailsPage in src/libs/ReportUtils.ts:6180-6193 is the single point that builds the destination URL for both menu entry points. After ruling out self-DMs and one-on-one chats, it pushes whatever report.reportID it was handed, with no validation:

// src/libs/ReportUtils.ts:6180-6193 (current)
function navigateToDetailsPage(report: OnyxEntry<Report>, backTo?: string, shouldUseActiveRoute?: boolean) {
    const isSelfDMReport = isSelfDM(report);
    const isOneOnOneChatReport = isOneOnOneChat(report);
    const participantAccountID = getParticipantsAccountIDsForDisplay(report);

    if (isSelfDMReport || isOneOnOneChatReport) {
        Navigation.navigate(ROUTES.PROFILE.getRoute(participantAccountID.at(0), isSelfDMReport || shouldUseActiveRoute ? Navigation.getActiveRoute() : backTo));
        return;
    }

    if (report?.reportID) {
        Navigation.navigate(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(report?.reportID, backTo));
    }
}

Two distinct ways the reportID it receives points at a record that isn't in the report_ Onyx collection:

1 - Placeholder bucket IDs leak through to the route. src/CONST/index.ts:1317-1319 defines three sentinel report IDs:

UNREPORTED_REPORT_ID: '0',
TRASH_REPORT_ID: '-1',
SPLIT_REPORT_ID: '-2',

These are used as transaction grouping buckets, not real reports — they never have a corresponding ${ONYXKEYS.COLLECTION.REPORT}{id} entry. When a user opens an unreported expense (transaction whose reportID === '0'), the transaction-thread context resolves report.reportID to that placeholder. The transaction-level handler in src/components/MoneyRequestHeaderSecondaryActions.tsx:395-402 then passes the placeholder straight in:

[CONST.REPORT.TRANSACTION_SECONDARY_ACTIONS.VIEW_DETAILS]: {
    value: CONST.REPORT.SECONDARY_ACTIONS.VIEW_DETAILS,
    text: translate('iou.viewDetails'),
    icon: expensifyIcons.Info,
    onSelected: () => {
        navigateToDetailsPage(report, Navigation.getActiveRoute());
    },
},

Navigation.navigate lands on r/0/details (or r/-1/details, r/-2/details). withReportOrNotFound (src/pages/inbox/report/withReportOrNotFound.tsx:101-122) computes isReportLoaded = !isEmptyObject(report) && !!report?.reportID, sees no record, fires openReport({reportID: '0'}), and once reportLoadingState.isLoadingInitialReportActions flips to false, shouldShowNotFoundPage becomes true → "Hmm... it's not here."

2 - VIEW_DETAILS is pushed unconditionally even when the underlying report can't render details. src/libs/ReportSecondaryActionUtils.ts:1015 and :1098 both append the action with no guard:

// src/libs/ReportSecondaryActionUtils.ts:1015
options.push(CONST.REPORT.SECONDARY_ACTIONS.VIEW_DETAILS);
// :1098
options.push(CONST.REPORT.TRANSACTION_SECONDARY_ACTIONS.VIEW_DETAILS);

So the menu item shows for placeholder-bucketed reports, demo data, and any report whose reportID resolves to a sentinel — every one of those clicks ends on the not-found view.

Proposed fix

Centralize the guard inside navigateToDetailsPage so every caller is fixed at once, and fall through to the parent chat report when the directly-passed report is a placeholder bucket. The parent chat (policyExpenseChat / DM owning the IOU) is always loaded in Onyx alongside the IOU record and can render details.

// src/libs/ReportUtils.ts (replace the body at 6180-6193)
function navigateToDetailsPage(report: OnyxEntry<Report>, backTo?: string, shouldUseActiveRoute?: boolean) {
    const isSelfDMReport = isSelfDM(report);
    const isOneOnOneChatReport = isOneOnOneChat(report);
    const participantAccountID = getParticipantsAccountIDsForDisplay(report);

    if (isSelfDMReport || isOneOnOneChatReport) {
        Navigation.navigate(ROUTES.PROFILE.getRoute(participantAccountID.at(0), isSelfDMReport || shouldUseActiveRoute ? Navigation.getActiveRoute() : backTo));
        return;
    }

    const reportID = report?.reportID;
    const isPlaceholderBucket =
        !reportID ||
        reportID === CONST.REPORT.UNREPORTED_REPORT_ID ||
        reportID === CONST.REPORT.TRASH_REPORT_ID ||
        reportID === CONST.REPORT.SPLIT_REPORT_ID;

    if (isPlaceholderBucket) {
        // Sentinel buckets ('0', '-1', '-2') have no Onyx report record;
        // navigating to them lands on the not-found page. Walk up to the parent chat instead.
        const parentChatReportID = report?.parentReportID;
        if (parentChatReportID) {
            Navigation.navigate(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(parentChatReportID, backTo));
        }
        return;
    }

    Navigation.navigate(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(reportID, backTo));
}

Then stop emitting the action when there's no resolvable target, so the menu doesn't advertise a no-op. In src/libs/ReportSecondaryActionUtils.ts, replace line 1015:

// src/libs/ReportSecondaryActionUtils.ts:1015
const reportIDForDetails = report?.reportID;
const canViewReportDetails =
    !!reportIDForDetails &&
    reportIDForDetails !== CONST.REPORT.UNREPORTED_REPORT_ID &&
    reportIDForDetails !== CONST.REPORT.TRASH_REPORT_ID &&
    reportIDForDetails !== CONST.REPORT.SPLIT_REPORT_ID;
if (canViewReportDetails) {
    options.push(CONST.REPORT.SECONDARY_ACTIONS.VIEW_DETAILS);
}

And the matching change at line 1098, using parentReport?.reportID (the IOU/expense report owning the transaction thread) since getSecondaryTransactionThreadActions already takes parentReport as a parameter:

// src/libs/ReportSecondaryActionUtils.ts:1098
const parentReportIDForDetails = parentReport?.reportID;
const canViewTransactionDetails =
    !!parentReportIDForDetails &&
    parentReportIDForDetails !== CONST.REPORT.UNREPORTED_REPORT_ID &&
    parentReportIDForDetails !== CONST.REPORT.TRASH_REPORT_ID &&
    parentReportIDForDetails !== CONST.REPORT.SPLIT_REPORT_ID;
if (canViewTransactionDetails) {
    options.push(CONST.REPORT.TRANSACTION_SECONDARY_ACTIONS.VIEW_DETAILS);
}

Why this approach

navigateToDetailsPage is the only chokepoint for this navigation — fixing it there means every caller (the report-level menu in MoneyReportHeaderSecondaryActions.tsx:343, the transaction-thread menu in MoneyRequestHeaderSecondaryActions.tsx:400, AvatarWithDisplayName.tsx:230, HeaderView.tsx:314, ReportActionItemCreated.tsx:62) inherits the placeholder-bucket guard for free. The action-list change is defense in depth: without it, the menu still surfaces a "View details" item for unreported / trash / split transactions, then silently no-ops via the new early-return — the cleaner UX is to not render the entry at all when it can't resolve.

Rewriting each caller to pass chatReport / parentReport instead was considered but rejected: ReportDetailsPage is already designed to render three caseID branches (CASES.MONEY_REPORT, CASES.MONEY_REQUEST, CASES.DEFAULT at src/pages/ReportDetailsPage.tsx:257-267) for IOU reports, transaction threads, and chat threads respectively. The IDs the menus pass today are the right targets when they're real — the bug is only that the helper accepts sentinel placeholders without filtering them.

[ohrytskov]

Proposal: Pre-Navigation Report Data Validation

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

Clicking "View Details" from an expense/report actions menu renders the "Hmm... it's not here" not-found page instead of opening the details panel. This happens because navigateToDetailsPage() navigates without validating that report data is available in the Redux store.

What is the root cause of that problem?

The navigateToDetailsPage() function in src/libs/ReportUtils.ts:6121-6134 only checks if report?.reportID exists before navigating. It doesn't validate:

1. Whether the report object is fully hydrated with necessary fields
2. Whether report data fetching is complete

When data is missing, the destination component shows the not-found page.

What changes do you think we should make to fix this problem?

Add pre-flight validation to navigateToDetailsPage() and its callers to ensure report data is ready before navigation. If data is incomplete, skip navigation silently and log a warning.

Where should the changes be made?

1. src/libs/ReportUtils.ts (lines 6121-6134)

 function navigateToDetailsPage(report: OnyxEntry<Report>, backTo?: string, shouldUseActiveRoute?: boolean) {
+    if (isEmptyObject(report)) {
+        Log.warn('navigateToDetailsPage: Report data is empty, skipping navigation');
+        return;
+    }
+
     const isSelfDMReport = isSelfDM(report);
     const isOneOnOneChatReport = isOneOnOneChat(report);
     const participantAccountID = getParticipantsAccountIDsForDisplay(report);

     if (isSelfDMReport || isOneOnOneChatReport) {
+        if (!participantAccountID?.length) {
+            Log.warn('navigateToDetailsPage: Participant data missing, skipping navigation');
+            return;
+        }
         Navigation.navigate(ROUTES.PROFILE.getRoute(participantAccountID.at(0), isSelfDMReport || shouldUseActiveRoute ? Navigation.getActiveRoute() : backTo));
         return;
     }

     if (report?.reportID) {
         Navigation.navigate(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(report?.reportID, backTo));
+    } else {
+        Log.warn('navigateToDetailsPage: Report ID missing, skipping navigation');
     }
 }

2. src/components/MoneyRequestHeaderSecondaryActions.tsx (lines 395-402)

 [CONST.REPORT.TRANSACTION_SECONDARY_ACTIONS.VIEW_DETAILS]: {
     value: CONST.REPORT.SECONDARY_ACTIONS.VIEW_DETAILS,
     text: translate('iou.viewDetails'),
     icon: expensifyIcons.Info,
     onSelected: () => {
+        if (isEmptyObject(report)) {
+            Log.warn('VIEW_DETAILS: Report data not available');
+            return;
+        }
         navigateToDetailsPage(report, Navigation.getActiveRoute());
     },
 },

3. Apply similar pattern to other callers:

• src/components/AvatarWithDisplayName.tsx
• src/components/MoneyReportHeaderActions/MoneyReportHeaderSecondaryActions.tsx
• src/pages/inbox/HeaderView.tsx
• src/pages/inbox/report/ReportActionItemCreated.tsx

Expected Result

• Navigation only happens when report data is available
• Silent skip if clicked while data is loading
• "Hmm... it's not here" page no longer appears due to timing issues

Implementation Notes

• Uses existing imports: Log (line 122), isEmptyObject (line 86) in ReportUtils.ts
• Non-breaking: only adds defensive guards