[Due for payment 2026-09-16] Android - Report-Skeleton loader briefly visible on expense created offline opened via card

@huult

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

Version Number: 9.4.74-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97308
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Money Requests

Action Performed:

Prerequisite: Account has a workspace.

Open the Expensify app.
Open any workspace chat.
Create a manual expense.
Turn off internet connection.
Create another manual expense.
Tap on the card of the expense created offline on report preview.
Note that before landing on the opened expense, skeleton loader and glitches are briefly experienced.

Expected Result:

After creating an expense while offline and navigating to it via card on report preview, user should automatically land on the expense RHP.

Actual Result:

Skeleton loader and glitches are briefly experienced after navigating to an expense created while offline via card on report preview.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7254633_1788910736909.Glitch.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7254633

Issue Owner

Current Issue Owner: @huult

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/d3f050c321b4a4b6e735cfce11e9f5f6c17331d923b1a60a19d9e6a78d9b45e3

You have been assigned to this deploy blocker because you recently merged this PR: #97308

@MonilBhavsar

@MonilBhavsar @huult you have been assigned to this deploy blocker because you reviewed the offending PR: #97308

💬 A slack conversation has been started in #expensify-open-source

👋 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:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@wildan-m

@wildan-m could you check this issue?

@wildan-m

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #97308 - "Navigate to the clicked expense in a multi-expense report preview (v2)" by @wildan-m (High confidence)
Related Issues: #100669 (same PR, same offline preview-press path, "It's not here" RHP), #91042 (issue the PR fixes), #97149 / #97158 / #97183 / #97184 (the v1 blockers that led to the revert in #97198)

Recommendation: REVERT

Two deploy blockers in 9.4.74-0 (this one and #100669) both land on the new offline preview-press path added by #97308, which is itself a re-land of #92546 after that version was reverted in #97198 following five blockers — the offline branch of this flow is not stable enough to ship, and reverting restores the previous single-navigation behavior with no other dependencies. If product prefers to keep the feature, the surgical alternative is described in the Root Cause section below, but it should land as a v3 with the offline path covered rather than as a hotfix on top of a second blocker.

Assigned: @wildan-m (PR author), @MonilBhavsar and @huult (approving reviewers) from the causing PR
Labels: No changes. DeployBlockerCash is correct and stays (App-side regression, and the issue is not reproducible in production). DeployBlocker was never applied, so there is nothing to remove.

📋 Detailed Analysis

Evidence

The flow in the repro steps did not exist before Navigate to the clicked expense in a multi-expense report preview (v2) #97308. Before the PR, onPreviewPressed was openReportFromPreview, which performed exactly one navigation on a narrow layout: Navigation.navigate(ROUTES.REPORT_WITH_ID...). Navigate to the clicked expense in a multi-expense report preview (v2) #97308 replaced it with openTransactionFromPreview → navigateToExpense, which on a narrow layout navigates to the expense report first and then pushes the expense RHP after a 180ms timer: MoneyRequestReportPreview/index.tsx#L270-L295 (PRESSED_EXPENSE_CASCADE_DELAY). An intermediate screen is now always mounted and painted for at least 180ms plus the RHP transition — which is precisely the reported "skeleton loader and glitches ... before landing on the opened expense".
It is the only PR in this release that touches the preview-card press path. Of the PRs in the 9.4.74-0 checklist (Deploy Checklist: New Expensify 2026-09-08 #100624), only Navigate to the clicked expense in a multi-expense report preview (v2) #97308 modifies MoneyRequestReportPreview, useNavigateToTransactionThread, or TransactionThreadNavigation. refactor: the new-transaction highlight rail and the wide RHP width model #98744 also touches MoneyRequestReportPreview, but it merged at 2026-09-09T00:07Z, after the 9.4.74-0 cut, and is not on the checklist — so it is not a candidate here.
A sibling blocker exercises the same new code path. [Due for payment 2026-09-16] Report - "It´s not here" RHP opens after navigating to remaining split via preview offline. #100669 ("It's not here" RHP after pressing a preview card offline) is also attributed to Navigate to the clicked expense in a multi-expense report preview (v2) #97308 and is the same class as the v1 blocker [Due for payment 2026-09-16] Report - Expense deleted offline can still be opened and leads to "It´s not here" RHP. #97149 that this PR explicitly claimed to guard. Both blockers are offline + report-preview-card-press.
Staging only, by construction. The issue reports "N/A - new feature, doesn't exist in prod". Production still has the pre-Navigate to the clicked expense in a multi-expense report preview (v2) #97308 single navigation, so this cannot reproduce there.

Verification

Affected files (all touched by #97308):

src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx — +305 / -27 in the PR; owns the card press handler and the cascade.
src/hooks/useNavigateToTransactionThread.ts, src/libs/actions/TransactionThreadNavigation.ts, src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx — also modified by the PR.

Confirmed the PR modifies these files (gh pr view 97308 --json files) and that the cascade code above is present on staging at ab2d498 but absent from the pre-PR version of the same function (visible in the PR diff, where the small-screen branch was a single Navigation.navigate(ROUTES.REPORT_WITH_ID...)).

Screens the cascade passes through, and where they render loading states — these are pre-existing components that the new flow now walks through:

Intermediate expense report r/{iouReportID}: ReportFetchHandler.tsx#L398-L403 re-arms isLoadingInitialReportActions: true for a report whose actions were never loaded, and MoneyRequestReportActionsList.tsx#L162 computes showReportActionsLoadingState without an isOffline guard (unlike isInitialReportLoadPending on the very next line).
The transaction thread in the RHP: MoneyRequestReportView.tsx#L213-L223 returns ReportActionsSkeletonView while the (brand new) thread has no report actions yet, and MoneyRequestView.tsx#L1184 returns ReportActionsSkeletonView until transactionThreadReport?.reportID resolves.

The navigation cascade is the necessary cause either way; which of these two skeleton branches is on screen in the recording is medium confidence, since offline Android was not run as part of this investigation.

Root Cause

For an offline-created manual expense there is no transaction thread to open, so the press has to mint one and then walk two screens to get to it:

Manual expense creation deliberately builds no optimistic transaction thread — useExpenseSubmission.ts#L212 hardcodes shouldGenerateTransactionThreadReport = false. So the optimistic IOU action carries no childReportID, and transaction.transactionThreadReportID is undefined.
On press, resolveChildReportID therefore falls through to createTransactionThreadReport(...), which mints a client-side thread report and calls openReport with it. openReport's optimistic data sets isLoadingInitialReportActions: true for that report and only the success/failure updates clear it — neither can arrive while offline, because the request just sits in the queue.
openTransactionFromPreview has an offline bail-out, but it is guarded by !isIOUActionLoaded. For an expense created in this session the optimistic IOU action is loaded, so the offline branch is skipped and navigateToExpense runs.
navigateToExpense then pushes r/{iouReportID}, waits 180ms, and pushes the expense RHP. Both of those screens are in a "still loading" state that offline can never resolve, so their skeletons are visible for the whole cascade instead of being replaced by content the way they are online.

Contrast with the row-press path inside the report, which is unaffected: useNavigateToTransactionThread.ts#L94-L102 navigates straight to SEARCH_REPORT with no intermediate report push and no timer, and shows no flash.

If the feature is kept instead of reverted, the surgical fix is to stop entering the cascade when the thread has to be minted offline — i.e. in openTransactionFromPreview, when isOffline and resolveChildReportID had no pre-existing childReportID (no iouAction.childReportID and no transaction.transactionThreadReportID), fall back to openReportFromPreview(), the same way the pending-DELETE case already does a few lines above. That both removes the flash and avoids minting a client-side thread ID that the server will replace with its own once the queued RequestMoney flushes. Widening the skeleton gates instead (e.g. adding !isOffline to showReportActionsLoadingState) would touch loading logic shared by every report and is the riskier change to make under deploy pressure.

Same PR: #100688. On narrow layouts the press opened the parent report and pushed the expense 180ms later, so the report showed loading first. Both are pushed in the same tick now. Back still goes expense → report → chat.

iOS simulator, expense created offline, then its card:

100673-ios-fix-offline-expense-card-tap.mp4

Xiaomi Redmi Note 10 / Android 12
App 9.4.74-2
Passed

Screenrecorder-2026-09-09-21-07-26-153.mp4

Amazing, thanks!

@huult

@huult

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

[CP Staging] Fix expense card press in the report preview: torn-down thread and narrow-layout cascade #100688

If no regressions arise, payment will be issued on 2026-09-16. 🎊

The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ 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]. If no checklist is needed for this issue, you can click: [no checklist button]

Navigation Menu

Repository navigation

[Due for payment 2026-09-16] Android - Report-Skeleton loader briefly visible on expense created offline opened via card #100673

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

🔍 Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-09-16] Android - Report-Skeleton loader briefly visible on expense created offline opened via card #100673

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

applause-bot commented on Sep 9, 2026

melvin-bot commented on Sep 9, 2026

melvin-bot commented on Sep 9, 2026

melvin-bot commented on Sep 9, 2026

github-actions commented on Sep 9, 2026

huult commented on Sep 9, 2026

MelvinBot commented on Sep 9, 2026

🔍 Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

wildan-m commented on Sep 9, 2026

m-natarajan commented on Sep 9, 2026

MonilBhavsar commented on Sep 9, 2026

melvin-bot commented on Sep 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions