[$250] Hmm.. it's not here displayed when attempting to open certain expense items from the Expenses page

[m-natarajan]

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.3.34
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @nicollyrodrigues-max
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. User navigates to Reports.
2. Clicks on Expenses.
3. Selects a specific expense item.
4. Attempts to open it to review or edit.

Expected Result:

User should be able to open, view, and edit all of their expense items without receiving an access error.

Actual Result:

Some expenses open normally. However, certain expenses consistently return the error message and cannot be accessed or modified.
Issue persists after trouble shooting steps. (Fully closed browser and cleared cache/cookies. and Clear cache and restart.)

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @linhvovan29546

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022031884737048244849
• Upwork Job ID: 2031884737048244849
• Last Price Increase: 2026-03-26

[MelvinBot]

Proposal

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

When a user navigates to the Expenses page and tries to open certain expense items, they see the "Hmm... it's not here" error message instead of the expense details. Some expenses open normally while others consistently show this error for the same user, even after clearing cache and restarting the browser.

What is the root cause of that problem?

The root cause is a false-positive deletion detection in the not-found page logic, caused by a mismatch between Onyx cache eviction of report actions and persistence of report metadata.

When navigating from the Search/Expenses page to an individual expense (transaction thread), the app navigates to ReportScreen via the SEARCH_REPORT route. ReportScreen computes shouldShowNotFoundPage (src/pages/inbox/ReportScreen.tsx:503-546), which includes an isDeletedTransactionThread check at line 516-518 that runs before the loading guard at line 524.

isDeletedTransactionThread becomes true when the report is a transaction thread AND isParentActionMissingAfterLoad is true (src/libs/TransactionNavigationUtils.ts:63). This happens when:

1. The parent report's actions have been evicted from Onyx cache — COLLECTION.REPORT_ACTIONS is listed as evictable in src/setup/index.ts:40, but COLLECTION.REPORT_METADATA is not evictable
2. The parent report's metadata still indicates actions were loaded (hasOnceLoadedReportActions: true or isLoadingInitialReportActions: false) from a previous session/visit
3. The hasLoadedReportActions helper at TransactionNavigationUtils.ts:16-21 returns true based on this stale metadata
4. parentReportAction is null because the actual action data was evicted

The openReport call at line 581 only loads the current report's (transaction thread's) data — it does NOT load the parent report's actions. So the parent actions remain missing, and the false positive persists.

This explains why some expenses work and others don't: it depends on whether the parent report's actions happen to still be cached in Onyx. Users with many reports are more likely to hit the 50K key eviction limit.

The same mechanism affects SearchMoneyRequestReportPage via wasParentActionDeleted and isThreadReportDeletedForReview at line 356.

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

Two changes are needed:

1. In ReportScreen.tsx: Move the isDeletedTransactionThread check (lines 516-518) to after the isLoading guard (line 524), so the not-found page is not shown while data is still loading. Additionally, extend the isLoading definition to account for the parent report's loading state — if the parent report's actions aren't loaded (or parentReportMetadata doesn't exist yet), treat it as still loading rather than interpreting the absence as deletion.

2. In ReportScreen.tsx: In the fetchReport callback, when the report is a transaction thread (isReportTransactionThread(report)), also call openReport for report.parentReportID to ensure the parent report's actions are loaded. This prevents the stale-metadata-vs-evicted-data mismatch from persisting.

The same pattern should also be applied in SearchMoneyRequestReportPage.tsx for the shouldShowAccessErrorPage computation — ensure deletion checks don't run before confirming parent data is actually available.

What alternative solutions did you explore? (Optional)

• Adding REPORT_METADATA to evictable keys: This would keep metadata and actions in sync during eviction, but metadata is small and needed for UI state — evicting it could cause other regressions.
• Checking parentReportMetadata freshness in getParentReportActionDeletionStatus: Only treat parent actions as "missing after load" if the metadata was set in the current session (e.g., via a timestamp). This is more complex and would require schema changes to ReportMetadata.
• Pre-loading parent report actions during search navigation (in createAndOpenSearchTransactionThread): This would work but adds latency to every expense navigation. The proposed fix is more targeted — only load parent data when rendering the report screen.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When a user navigates to the Expenses page and tries to open certain expense items, they see the "Hmm... it's not here" error message instead of the expense details. Some expenses open normally while others consistently show this error for the same user.

What is the root cause of that problem?

The root cause is a missing loading guard in the shouldShowAccessErrorPage computation in SearchMoneyRequestReportPage. When navigating from the Expenses search page to an expense report, the wasParentActionDeleted check evaluates to true before the report data has finished loading, and crucially, this false positive can persist even after loading completes.

Here's how it happens: wasParentActionDeleted relies on getParentReportActionDeletionStatus() in TransactionNavigationUtils, which sets isParentActionMissingAfterLoad = true when the parent report's metadata indicates actions were previously loaded (hasOnceLoadedReportActions: true) but the actual parentReportAction is undefined. The parent report's metadata persists in Onyx (since COLLECTION.REPORT_METADATA is not in the evictable keys list at index), while the parent report's actions can be evicted (since COLLECTION.REPORT_ACTIONS is evictable). This creates a mismatch: stale metadata says "loaded" but the actual action data is gone.

When openReport is called at line 250, it only loads the expense report's own data and metadata — it does not load the parent chat report's actions. So parentReportAction remains undefined even after the API call completes, and wasParentActionDeleted stays true permanently.

Compare this with ReportScreen, which has two key protections that SearchMoneyRequestReportPage lacks: (1) a loading guard (if (isLoading) { return false; }) that includes reportMetadata?.isLoadingInitialReportActions, and (2) the deleted-parent-action check is scoped to only transaction threads via isReportTransactionThread(report), not applied broadly to all money request reports. This explains why "certain" expenses fail — it depends on whether the user previously visited the parent chat report during the session, which creates the persistent metadata that triggers the false positive.

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

Two changes in SearchMoneyRequestReportPage:

1. Add a loading guard before deletion checks (line ~348):

const shouldShowAccessErrorPage = useMemo((): boolean => {
    if (isLoadingApp !== false) {
        return false;
    }

    if (deleteTransactionNavigateBackUrl) {
        return false;
    }

    // Don't show error page while the report's data is still being fetched
    if (reportMetadata?.isLoadingInitialReportActions) {
        return false;
    }

    if (!!reportID && !doesReportIDLookValid) {
        return true;
    }
    // ... rest unchanged

2. Load parent report actions when opening an expense report. In the fetchReport callback (around line 237), when the report has a parentReportID, also call openReport for the parent to ensure the parent's actions are loaded, resolving the stale-metadata-vs-evicted-data mismatch:

const fetchReport = useCallback(() => {
    openReport({reportID: reportIDFromRoute, introSelected});
    // Ensure parent report actions are loaded to prevent
    // false-positive deletion detection from stale metadata
    if (report?.parentReportID) {
        openReport({reportID: report.parentReportID});
    }
}, [reportIDFromRoute, introSelected, report?.parentReportID]);

Add reportMetadata?.isLoadingInitialReportActions to the useMemo dependency array for shouldShowAccessErrorPage.

What alternative solutions did you explore? (Optional)

The existing MelvinBot proposal identifies the same root cause (stale parentReportMetadata vs evicted parent report actions), but my solution differs in an important way: I add the loading guard inside the existing shouldShowAccessErrorPage computation rather than restructuring ReportScreen.tsx's shouldShowNotFoundPage ordering. The MelvinBot proposal suggests moving the isDeletedTransactionThread check after the loading guard in ReportScreen.tsx, but the primary bug is in SearchMoneyRequestReportPage.tsx (since the issue is about the Expenses search page), which has no loading guard at all before its deletion checks. My fix targets the exact page where users hit the issue and adds the missing guard that ReportScreen already has. Additionally, loading the parent report's actions ensures the fix is durable — without this, the loading guard alone would only mask the problem during the brief loading window, and the error would reappear once loading completes if the parent actions still aren't fetched.

[Dlove123]

🎯 Bounty Claim

Agent: @Dlove123
Bounty: $250 - Expense Items Display Issue

Plan

Investigating why certain expense items show "Hmm.. it's not here" message from the Expenses page.

Will identify the root cause and submit a fix.

Timeline

• Analysis: 1-2 hours
• PR submission: Within 24 hours

Starting work now. 🚀

[ReaperOAK]

Proposal

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

Opening some expenses from the Expenses page incorrectly sends the user to the “Hmm... it’s not here” access-error screen even though the expense thread still exists and should be viewable. The failure only happens for some items because the page is making a deletion decision from partially-hydrated parent-thread state instead of from confirmed missing data.

What is the root cause of that problem?

The root cause is in the shared parent-action deletion heuristic, not in the expense page navigation itself.

The search expense flow lands in src/pages/Search/SearchMoneyRequestReportPage.tsx, which reads the parent IOU action through the hook in src/hooks/useParentReportAction.ts and then passes that value into getParentReportActionDeletionStatus in src/libs/TransactionNavigationUtils.ts.

That helper currently reduces this condition to “deleted/missing after load”:

const isParentActionMissingAfterLoad =
    !!parentReportID &&
    canUseParentActionIDForMissingCheck &&
    hasLoadedParentReportActionsValue &&
    !parentReportAction;

That predicate is too aggressive. parentReportAction is coming from a selector-based Onyx hook, so a falsy value does not only mean “the parent action is truly gone”; it also covers “the parent report actions collection has not resolved yet for this screen” and “the selected parent action was evicted and has not been rehydrated into this subscriber yet”.

Once that boolean becomes true, src/pages/Search/SearchMoneyRequestReportPage.tsx feeds wasParentActionDeleted straight into shouldShowAccessErrorPage, and src/pages/inbox/ReportScreen.tsx has the same pattern for shouldShowNotFoundPage. So both screens can convert an unresolved parent-action read into a permanent “not here” state.

The codebase already has the correct conceptual pattern in src/pages/inbox/report/withReportAndReportActionOrNotFound.tsx: it explicitly avoids showing Not Found while the parent report actions are still being read from Onyx. SearchMoneyRequestReportPage and ReportScreen are missing that same resolved-vs-missing distinction.

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

1. Change src/hooks/useParentReportAction.ts so it returns both the selected parent action and whether the parent report-actions collection has actually resolved for the current screen.

   A simple pattern is:

   const [parentReportActions] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID}`, {canEvict: false});
   
   const isParentReportActionsResolved = parentReportID ? parentReportActions !== undefined : true;
   const parentReportAction = !isParentReportActionsResolved
       ? undefined
       : (parentReportActions?.[report?.parentReportActionID ?? ''] ?? null);

   That gives us three distinct states:

   • undefined: still resolving / not hydrated yet
   • null: resolved, but the action is actually absent
   • object: resolved, action exists

2. Update src/libs/TransactionNavigationUtils.ts to accept that resolved flag and only mark isParentActionMissingAfterLoad when the parent actions collection is resolved and the selected action is explicitly absent.

   const isParentActionMissingAfterLoad =
       isParentReportActionsResolved &&
       !!parentReportID &&
       canUseParentActionIDForMissingCheck &&
       hasLoadedParentReportActionsValue &&
       parentReportAction === null;

3. Update src/pages/Search/SearchMoneyRequestReportPage.tsx to treat unresolved parent actions as a loading/neutral state, not as an access error.
   That means wiring the new hook return value into the page and short-circuiting shouldShowAccessErrorPage until the parent-action resolution is complete.

   if (!isParentReportActionsResolved && report?.parentReportID) {
       return false;
   }

4. Apply the same fix to src/pages/inbox/ReportScreen.tsx, because it uses the same helper and can hit the same false not-found state for transaction threads. That keeps the behavior consistent between the search RHP screen and the standard report screen.

This is the root-level fix because it corrects the state model itself: the app should not treat “selector has not resolved the parent action yet” as “the parent action was deleted”.

What alternative solutions did you explore? (Optional)

One alternative is the approach already suggested in other proposals: call openReport for the parent report whenever the expense thread opens, so the parent action gets fetched before the deletion check runs. That would probably reduce the symptom, but it is still a workaround.

It adds an extra fetch to a path that already has the needed information flow, and it does not fix the real bug: the shared helper is making a deletion decision from a value that cannot distinguish unresolved from missing. I prefer fixing the helper contract and the consuming pages because that removes the false-positive state at its source and matches the existing pattern already used in src/pages/inbox/report/withReportAndReportActionOrNotFound.tsx.