Report- Switch to ND, empty report created in OD loading

[applause-bot]

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.91-0
Reproducible in staging?: Yes
Reproducible in production?: No
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-37246/folder/13176703/41236809/1455622322
Email or phone of affected tester (no customers): lekima20+60806@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

Precondition: Admin invite an employee to a workspace

1. Open https://staging.new.expensify.com login as Employee
2. Go to Account > Troubleshoot > Switch to OldDot
3. Click on Reports tab
4. Click Create Report
5. Open https://staging.new.expensify.com in a new browser tab
6. Observe the report created in OD

Expected Result:

The report created in OD should display normally in ND

Actual Result:

The report created in OD is loading in ND

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169399_1780390265056.Recording__2170.mp4

View all open jobs on GitHub

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

[applause-bot]

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

[melvin-bot]

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

[mollfpr]

@MelvinBot Find the PR that causing this regression.

[MelvinBot]

Issue Analysis

Root Cause: When ND opens an empty money-request/expense report, the loading skeleton is gated by shouldWaitForTransactions() (called from ReportActionsList.tsx:47). For an empty report whose total is undefined, the clause report?.total !== 0 at MoneyRequestReportUtils.ts:145 evaluates to undefined !== 0 → true, so isStillLoadingData stays true permanently and the skeleton never clears.

⚠️ Important: This gate function and all of its App-side inputs are byte-for-byte identical to production (9.3.90-3) — openReport, the loading-state flags, and the report-total handling are unchanged in this release. So this is not an App logic regression. The regression is a data change: in this release the OD-created empty report now arrives with total unset (or a changed report type) where production effectively had total: 0. That payload comes from OldDot / the backend, which is outside the Expensify/App repo.

Recommended Next Steps:

• Primary (root cause — outside App): An internal engineer with backend access should check what changed in 9.3.91-0 for the OldDot "Create Report" payload of an empty report — specifically whether total is now omitted instead of 0, or whether the report type changed. That backend/submodule change is the actual regression and the likely revert target. This cannot be fixed in the App repo.
• Optional App-side hardening (mitigation, not a root-cause fix): make shouldWaitForTransactions treat an empty report with total === undefined as "loaded" once report actions have arrived, so it can't hang. This only masks the symptom.

Investigation details

Symptom: Empty report created in OD → opened in ND (Win 11/Chrome) → stuck on loading skeleton, never renders. Reproducible in staging v9.3.91-0, not in production.

Where the skeleton comes from: ReportActionsList.tsx:47-49 returns <ReportActionsSkeletonView /> whenever shouldWaitForTransactions is true.

Why it hangs (mechanism, high confidence):

isStillLoadingData =
    transactions.length === 0 &&
    ( (isLoadingInitialReportActions && !hasOnceLoadedReportActions)  // clears after OpenReport
      || report?.total !== 0                                          // TRUE forever if total is undefined
      || hasPendingDismissWrite )

For an empty expense report: transactions.length === 0 is true, and report?.total !== 0 is undefined !== 0 → true. Even after OpenReport succeeds and flips the loading flags, the total clause keeps isStillLoadingData true, so the gate returns true forever.

Why this is a data regression, not a code regression:

• git diff 9.3.90-3..HEAD on src/libs/MoneyRequestReportUtils.ts, src/hooks/useReportTransactionsCollection.ts, and src/libs/actions/OnyxDerived/** → no changes.
• src/libs/actions/Report/index.ts changed, but none of the changes touch openReport, hasOnceLoadedReportActions, isLoadingInitialReportActions, or total (the diff is unrelated delegateAccountID work).
• src/libs/ReportUtils.ts changed only for delegateAccountID plumbing.
• Since prod (9.3.90-3) runs the identical gate and does not repro, the difference must be in the report payload (total / type) supplied by OldDot.

Two failure modes produce this same skeleton — which one?

1. Data (favored): report.total is undefined for the empty report → total clause hangs. Consistent with the narrow symptom (only the one new empty report hangs; the rest of ND loads fine).
2. Network: OpenReport never completes so loading flags never clear. Less likely — a broken network layer would stall many reports, not just one empty one.

Verification to confirm (logs): For the reporting tester around the repro time, check whether OpenReport for the new report returned 200 and whether the resulting ${REPORT}${reportID} Onyx record has total set. If OpenReport succeeds but total stays undefined → confirms failure mode 1 (data/backend trigger).

Confidence: Medium — mechanism is high-confidence with file:line evidence; the exact triggering change is unconfirmed and appears to live outside the App repo.

---

Next Steps for Contributor+ team:
To investigate the root cause: escalate to an internal engineer to identify the OldDot/backend change to the empty-report payload (this is outside Expensify/App and is the likely revert candidate).
To refine: @MelvinBot <your feedback>

[MelvinBot]

Regression PR — leading suspect

#91166 ("Guard PERSISTED_ONGOING_REQUESTS callback against own-write stale overwrites"), together with its sibling #91948 ("distinguish client requestIndex from server requestID"). Both [NoQA], both merged 2026-06-01 — the day before this blocker.

Why: The repro is multi-tab ("open ND in a new browser tab"). #91166 adds a brand-new early-return in the PERSISTED_ONGOING_REQUESTS Onyx callback that silently drops an ongoing request it judges to be an "own-write" (PersistedRequests.ts:182-187). The judgment key was switched (by #91948) from the server-assigned, globally-unique requestID to the client-assigned requestIndex (PersistedRequests.ts:36). requestIndex is a per-tab counter, so values collide across tabs — the new ND tab can mistake the other tab's in-flight OpenReport for its own write and skip it. OpenReport then never applies its success data (hasOnceLoadedReportActions: true), so the report sits on the loading skeleton forever.

⚠️ This refines my earlier comment. Using the authoritative production...staging compare API (my earlier local diff was against a tag that doesn't exist in this shallow clone — it silently returned nothing), I've confirmed the loading-skeleton gate and the report-rendering layer are genuinely unchanged this release. So this is not a rendering bug — but it is not necessarily outside App as I previously said. The only release changes that can produce a permanent loading skeleton are in the request/queue layer, and #91166/#91948 are the prime movers there.

Confidence: Medium — strong code + timing + repro-shape match, but not runtime-confirmed (VictoriaLogs was unavailable in this run, and I couldn't reproduce).

Evidence, ruling-out, and how to confirm

The skeleton gate is unchanged (authoritative production...staging compare):

• src/libs/MoneyRequestReportUtils.ts (the shouldWaitForTransactions gate) — not in the changed-file list.
• src/pages/inbox/ReportActionsList.tsx (the orchestrator that renders the skeleton) — not in the changed-file list.
• src/libs/ReportUtils.ts — only delegateAccountID plumbing changed; no change to isExpenseReport/isMoneyRequestReport/report-type classification or total.
• src/libs/TransactionUtils/index.ts — only adds an unused getIsFromGlobalCreate helper.
• → No report-rendering PR changes the gate's inputs (report type, total, transactions). The hang must come from the load itself never completing.

The new skip logic (#91166):

// src/libs/actions/PersistedRequests.ts  (PERSISTED_ONGOING_REQUESTS callback)
const requestIndex = val ? getClientRequestIndex(val) : undefined;
if (requestIndex != null && knownOngoingRequestIDs.has(requestIndex)) {
    Log.info('[PersistedRequests] Ignoring ongoingRequest that is an own-write', false, {ongoingCommand: val?.command});
    return;   // ← ongoing request dropped; its response/onyxData never processed
}

getClientRequestIndex = requestIndex ?? requestID (line 36), and knownOngoingRequestIDs is populated from this tab's own writes (line 371-373). Because requestIndex is a client-side per-tab counter (that's the whole point of #91948 — "distinguish client requestIndex from server requestID"), two tabs reuse the same small integers, so cross-tab false-positives are expected.

Why the load hangs once the request is dropped: the orchestrator shows <ReportActionsSkeletonView /> until OpenReport flips hasOnceLoadedReportActions: true. If the ongoing OpenReport is skipped, that flip never lands → permanent skeleton. (For an expense report there's a second way to hang — report.total !== 0 when total is undefined — but since no App code changed that path, the request-drop is the more likely trigger here.)

Secondary suspect: #92258 ("Enable react-native-nitro-fetch") also touches the web request path (HttpUtils.ts, Request.ts). Less likely than #91166 because it isn't specific to the multi-tab scenario, but worth keeping on the list.

Fallback: a backend/OldDot change to the empty-report payload (total omitted). No App rendering PR changes this, so it's only in play if the verification below clears the request-layer PRs.

How to confirm quickly:

1. Repro + console: during the repro, watch the ND console/Grace logs for [PersistedRequests] Ignoring ongoingRequest that is an own-write. If it fires for an OpenReport/ReconnectApp command, that's the smoking gun for [NoQA] Guard PERSISTED_ONGOING_REQUESTS callback against own-write stale overwrites #91166.
2. Network tab: check whether OpenReport for the new report actually returns and whether its onyxData is applied. If the request is dropped client-side, you won't see its effects.
3. Revert test: revert #91166 (and likely #91948, since the two are coupled) on a test build and re-run the multi-tab flow.

All three PRs here are [NoQA], so this multi-tab path was not manually exercised before merge.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine, or confirm via the steps above and revert the implicated PR(s).