[$250] iOS - Report - Expense report loads infinitely after deleting one split

[mitarachim]

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.70-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #88075
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 13 iOS 26.3.1
App Component: Money Requests

Action Performed:

1. Open the app
2. Navigate to workspace chat and create report
3. Add expense
4. Split expense from step 2
5. Open one of child expenses
6. Click More > Edit splits
7. Select one split
8. Remove split
9. Click save

Expected Result:

After deleting a split, the expense report should load normally and display the expense details without swiping.

Actual Result:

After deleting one split, the expense report gets stuck loading indefinitely, but it loads after a swipe gesture.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7151488_1778558026742.ScreenRecording_05-11-2026_22-37-15_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054115829956745675
• Upwork Job ID: 2054115829956745675
• Last Price Increase: 2026-06-16

Issue Owner

Current Issue Owner: @puneetlath

[MelvinBot]

Proposal

What is the root cause of that problem?

After removing a split, the report page shows an infinite loading skeleton because of a timing mismatch between transaction deletion and report total updates.

The shouldWaitForTransactions function returns true (showing a skeleton) when transactions.length === 0 && report.total !== 0. During a reverse split operation (reducing from 2 splits to 1), the child transactions are deleted optimistically via the derived REPORT_TRANSACTIONS_AND_VIOLATIONS value, making transactions.length === 0 before the report's total field is updated to reflect the change — so the condition evaluates to true and the skeleton appears.

On iOS specifically, this is exacerbated by two layers of deferred execution:

1. In MoneyRequestHeaderSecondaryActions.tsx:443, the deleteTransactions call is wrapped in InteractionManager.runAfterInteractions, which on iOS waits for all native animations (including the dismiss modal animation) to complete before firing.
2. In DeleteMoneyRequest.ts:461, the remaining Onyx updates (including report total) are also deferred behind InteractionManager.runAfterInteractions.

If the iOS navigation animation doesn't properly signal completion, these deferred callbacks stall — leaving the report in a state where transactions are empty but report.total !== 0. The skeleton persists until a swipe gesture forces a React Native bridge flush and triggers a re-render.

The ReportActionsList.tsx:47-49 component is where the skeleton is rendered:

if (!report || shouldWaitForTransactions) {
    return <ReportActionsSkeletonView />;
}

Note: PR #88075 (which fixed the original issue #87094) only modified the forward split code path in SplitTransactionUpdate.ts — it did not address this timing issue in the reverse split / delete path.

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

The fix should ensure the report total is updated synchronously with the transaction deletion in the optimistic data, so that shouldWaitForTransactions never sees the intermediate state of transactions.length === 0 && report.total !== 0.

Specifically, in SplitTransactionUpdate.ts, when isLastTransactionInReport is true and the report is being soft-deleted, the optimistic data should also set total: 0 on the report. This way, even if InteractionManager.runAfterInteractions is delayed on iOS, shouldWaitForTransactions will evaluate report.total !== 0 as false and skip the skeleton.

Additionally, review the InteractionManager.runAfterInteractions usage in MoneyRequestHeaderSecondaryActions.tsx:443 — consider whether the transaction deletion truly needs to be deferred until after animations, or if it can run immediately to avoid this class of timing issues on iOS.

What alternative solutions did you explore?

An alternative would be to modify shouldWaitForTransactions to also check for a pendingFields.preview === DELETE on the report, which would indicate the report is being deleted and shouldn't show a loading skeleton. However, this is a more fragile approach since it couples the loading logic to the delete pending state. Ensuring the optimistic data is consistent (total matches transaction count) is a cleaner fix.

Investigation details

Key code locations:

• MoneyRequestReportUtils.ts:133-152 — shouldWaitForTransactions function
• ReportActionsList.tsx:47-49 — skeleton rendering gate
• SplitTransactionUpdate.ts:1190-1201 — reverse split optimistic data (sets reportID: null but not total: 0)
• MoneyRequestHeaderSecondaryActions.tsx:443-446 — InteractionManager.runAfterInteractions wrapping delete
• DeleteMoneyRequest.ts:458-468 — deferred Onyx updates

Data flow:

1. User removes a split → triggers reverse split or deleteMoneyRequest
2. Optimistic Onyx data deletes child transactions
3. Derived REPORT_TRANSACTIONS_AND_VIOLATIONS removes transactions → transactions.length === 0
4. report.total remains non-zero (not updated in optimistic data)
5. shouldWaitForTransactions returns true → skeleton shown
6. On iOS, InteractionManager defers the remaining updates until animations complete
7. If animation completion signal is delayed → skeleton persists indefinitely
8. Swipe gesture forces React Native bridge flush → re-render with correct data

Confidence: Medium — code evidence clearly shows the timing gap; iOS-specific InteractionManager behavior explains why this is platform-specific. No production logs were checked to confirm the exact stuck state values.

---

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.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-08 07:32:27 UTC.

Proposal

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

After a reverse split (2→1) — open a split child, Edit splits, remove one split, Save — the workspace expense report doesn't settle on the remaining expense. On iOS it hangs on the loading skeleton until a touch/swipe (the OP), and across platforms it can flash the Not Found page (@mukhrr's repro: #90309 (comment)).

What is the root cause of that problem?

Correcting my earlier RCA (the navigate/defer direction — @dmkt9's retest confirmed it doesn't fix it). The real cause is incomplete optimistic data on a workspace reverse split, and it is not iOS-specific — the same bad state is what produces @mukhrr's cross-platform Not Found.

In updateSplitTransactions, hasChanges starts false for an existing transaction:

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Line 692 in 7af4b0e

let hasChanges = !splitTransaction;

On a pure revert the single remaining split equals the original, so the field-diff loop empties transactionChanges. The reverse-split block then forces hasChanges = true only for selfDM — the workspace branch is skipped:

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 733 to 743 in 7af4b0e

	if (isReverseSplitOperation) {
	delete transactionChanges.transactionID;
	if (isSelfDMSplit) {
	// For revert selfDM splits, ALL field changes are already captured in
	// requestMoneyInformation.transactionParams (amount, date, merchant, category, etc.).
	for (const key of Object.keys(transactionChanges)) {
	delete transactionChanges[key as keyof typeof transactionChanges];
	}
	// Ensure moneyRequestInformationOnyxData is applied even though transactionChanges is now empty.
	hasChanges = true;
	}

And moneyRequestInformationOnyxData — the data that re-adds the original transaction (active pendingAction, expense-report reportID) — is gated behind hasChanges:

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 1211 to 1214 in 7af4b0e

	if (hasChanges) {
	onyxData.optimisticData?.push(...(moneyRequestInformationOnyxData.optimisticData ?? []));
	onyxData.successData?.push(...(moneyRequestInformationOnyxData.successData ?? []));
	onyxData.failureData?.push(...(moneyRequestInformationOnyxData.failureData ?? []));

So a workspace revert's optimistic batch is just the two child DELETEs with nothing restored, while total is still set correctly. The report is left at total !== 0 with an empty active-transaction set, and two guards trap that one frame:

• Not Found (cross-platform): wereAllTransactionsDeleted is true when the report has rows but none active —

  App/src/libs/MoneyRequestReportUtils.ts

  Lines 88 to 106 in 7af4b0e

  	function getAllNonDeletedTransactions(transactions: OnyxCollection<Transaction>, reportActions: ReportAction[], isOffline = false, includeOrphanedTransactions = false) {
  	return Object.values(transactions ?? {}).filter((transaction): transaction is Transaction => {
  	if (!transaction) {
  	return false;
  	}
  	if (transaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
  	return true;
  	}
  	const action = getIOUActionForTransactionID(reportActions, transaction.transactionID);
  	if (!action && includeOrphanedTransactions) {
  	return true;
  	}
  	if (action?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && isOffline) {
  	return true;
  	}
  	return !isDeletedParentAction(action) && (reportActions.length === 0 || !isDeletedAction(action));
  	});

• iOS stuck skeleton: the same window satisfies shouldWaitForTransactions (transactions?.length === 0 && report?.total !== 0) —

  App/src/libs/MoneyRequestReportUtils.ts

  Lines 143 to 145 in 7af4b0e

  	const isStillLoadingData =
  	transactions?.length === 0 &&
  	((!!reportLoadingState?.isLoadingInitialReportActions && !reportLoadingState.hasOnceLoadedReportActions) || report?.total !== 0 || hasPendingDismissWrite);

Why it only persists on iOS (answering @dmkt9's open question). The bad state is created on every platform. Web/Android repaint the instant RevertSplitTransaction's server onyxData lands and corrects the report; on iOS that correction is buffered (held in QueuedOnyxUpdates until the SequentialQueue has no ongoing request) behind the trailing ReadNewestAction, so it doesn't arrive promptly and the empty-transaction frame is what stays on screen. The crucial point: chasing the queue timing is the wrong layer. @rohit9625 just noted a tap does not reliably clear it (#90309 (comment)) — exactly what we'd expect if the cause is the missing optimistic restore rather than a queue that a touch could wake. Once the optimistic data is complete, the screen never enters the empty-transaction frame, so it no longer depends on when (or whether) the server response drains.

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

Restore the original transaction optimistically on every reverse split, not just selfDM, by lifting hasChanges = true out of the selfDM-only branch (keeping the field-clearing scoped to selfDM):

if (isReverseSplitOperation) {
    delete transactionChanges.transactionID;
    // Always restore the original optimistically on a revert so the report never renders a
    // "non-zero total with zero active transactions" frame (iOS skeleton / cross-platform Not Found).
    hasChanges = true;
    if (isSelfDMSplit) {
        // selfDM already captures every field change in requestMoneyInformation.transactionParams.
        for (const key of Object.keys(transactionChanges)) {
            delete transactionChanges[key as keyof typeof transactionChanges];
        }
    }
}

Only the pure-revert case changes: whenever transactionChanges is non-empty the diff already set hasChanges = true, so it stays a no-op everywhere else. With hasChanges = true, moneyRequestInformationOnyxData is applied in the same batch as the child deletes, so activeTransactionsCount is ≥ 1 on every frame — wereAllTransactionsDeleted can't fire (Not Found gone on all platforms) and the transactions?.length === 0 precondition the iOS skeleton depends on never holds.

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

In tests/actions/IOUTest, assert that a 2→1 workspace revert's optimistic data restores the original transaction (live pendingAction, correct expense-report reportID) alongside the two child deletes, so activeTransactionsCount is ≥ 1 throughout the optimistic window; and a regression guard that a non-revert split edit (transactionChanges non-empty) is unaffected.

What alternative solutions did you explore? (Optional)

• Navigate/dismiss first, then defer updateSplitTransactions (my earlier direction). Rejected — @dmkt9's retest showed it doesn't fix the report-screen repro, and it does nothing for the cross-platform Not Found, because the data is incomplete regardless of when the revert runs.
• Queue-level per-request flush / SequentialQueue surgery. Rejected — it patches shared network infra to mask a local data bug, and the per-request flush breaks the [Tracking] "Replay effect" when sequential actions are taken offline, and user subsequently comes online #12775 replay-ordering guarantee (that direction was retracted earlier in the thread).
• Gate shouldWaitForTransactions's report.total !== 0 clause on !hasOnceLoadedReportActions. Reasonable defense-in-depth for the skeleton, but it doesn't address the cross-platform Not Found and treats the symptom rather than the incomplete optimistic batch.

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-12 08:45:39 UTC.

Update after dmkt9's queue logs: this replaces my earlier ReportActionsList RCA. That branch can explain a downstream stale render, but the logs show the main infinite hang is earlier in the write queue: RevertSplitTransaction and OpenReport complete, then the queue stops progressing while ReadNewestAction is the ongoing request. Since write-response Onyx data is queued until SequentialQueue drains, that non-critical mark-read write can keep the reverted split data stale.

Proposal

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

After removing one split from an existing split expense and saving on iOS, the expense report should immediately settle with the remaining expense details. Instead, the report can stay stale/loading indefinitely until the user interacts with the UI, for example by swiping or tapping.

What is the root cause of that problem?

The verified failure is that SequentialQueue does not drain after it starts the non-critical ReadNewestAction write.

readNewestAction() marks the report as read using API.writeWithNoDuplicatesConflictAction(WRITE_COMMANDS.READ_NEWEST_ACTION, ...), so it is processed as a sequential write:

App/src/libs/actions/Report/index.ts

Lines 2688 to 2726 in eaaffe3

	function readNewestAction(reportID: string | undefined, hasOnceLoadedReportActions: boolean, shouldResetUnreadMarker = false) {
	if (!reportID) {
	return;
	}
	// Do not try to mark the report as read if the report has not been loaded and shared with the user.
	// However, if report actions already exist in Onyx (e.g., delivered via Pusher), the report is
	// clearly shared with the user and we can proceed with marking it as read.
	if (!hasOnceLoadedReportActions) {
	const reportActions = allReportActions?.[reportID];
	const hasReportActions = !!reportActions && Object.keys(reportActions).length > 0;
	if (!hasReportActions) {
	return;
	}
	}
	const lastReadTime = getDBTimeWithSkew();
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	lastReadTime,
	},
	},
	];
	const parameters: ReadNewestActionParams = {
	reportID,
	lastReadTime,
	};
	API.writeWithNoDuplicatesConflictAction(
	WRITE_COMMANDS.READ_NEWEST_ACTION,
	parameters,
	{optimisticData},
	(request) => request.command === WRITE_COMMANDS.READ_NEWEST_ACTION && request.data?.reportID === parameters.reportID,
	);

All write requests are pushed into SequentialQueue:

App/src/libs/API/index.ts

Lines 131 to 137 in eaaffe3

	async function processRequest<TKey extends OnyxKey>(request: OnyxRequest<TKey>, type: ApiRequestType): Promise<void | Response<TKey>> {
	Log.info('[API] Processing request', false, {command: request.command, type});
	// Write commands can be saved and retried, so push it to the SequentialQueue
	if (type === CONST.API_REQUEST_TYPE.WRITE) {
	Log.info('[API] Write command. Pushing to SequentialQueue', false, {command: request.command});
	await pushToSequentialQueue(request);
	return;

For write responses, applyHTTPSOnyxUpdates() does not apply server onyxData directly. It routes the updates through queueOnyxUpdates() so they are held until the sequential queue is flushed:

App/src/libs/actions/OnyxUpdates.ts

Lines 31 to 40 in eaaffe3

	function applyHTTPSOnyxUpdates<TKey extends OnyxKey>(request: Request<TKey>, response: Response<TKey>, lastUpdateID: number) {
	Log.info('[OnyxUpdateManager] Applying https update', false, {lastUpdateID});
	// For most requests we can immediately update Onyx. For write requests we queue the updates and apply them after the sequential queue has flushed to prevent a replay effect in
	// the UI. See https://github.com/Expensify/App/issues/12775 for more info.
	const updateHandler: (updates: Array<OnyxUpdate<TKey>>) => Promise<unknown> = request?.data?.apiRequestType === CONST.API_REQUEST_TYPE.WRITE ? queueOnyxUpdates : Onyx.update;
	// First apply any onyx data updates that are being sent back from the API. We wait for this to complete and then
	// apply successData or failureData. This ensures that we do not update any pending, loading, or other UI states contained
	// in successData/failureData until after the component has received and API data.
	const onyxDataUpdatePromise = response.onyxData ? updateHandler(response.onyxData) : Promise.resolve();

That queued data is only flushed in the final queue-drain path, when there are no remaining persisted or ongoing requests:

App/src/libs/Network/SequentialQueue.ts

Lines 356 to 382 in eaaffe3

	process().finally(() => {
	const remainingPersistedRequests = getAllPersistedRequests().length;
	const hasOngoingRequest = !!getPersistedOngoingRequest();
	const hasRemainingRequests = remainingPersistedRequests > 0 || hasOngoingRequest;
	Log.info('[SequentialQueue] Finished processing queue.', false, {
	remainingRequests: remainingPersistedRequests,
	isOffline: isOfflineNetwork(),
	willResolvePromise: isOfflineNetwork() || !hasRemainingRequests,
	});
	isSequentialQueueRunning = false;
	// Use isOfflineNetwork() — not isQueuePaused — to decide whether to resolve isReadyPromise.
	// isQueuePaused is true for both offline pauses AND shouldPauseQueue (data gap sync).
	// For shouldPauseQueue, WRITEs are still pending so READs must wait (don't resolve).
	// For offline, the queue can't process anyway so READs should proceed (resolve).
	if (isOfflineNetwork() || !hasRemainingRequests) {
	Log.info('[SequentialQueue] Resolving isReadyPromise', false, {
	reason: isOfflineNetwork() ? 'offline' : 'queue empty',
	});
	resolveIsReadyPromise?.();
	}
	currentRequestPromise = null;
	// The queue can be paused when we sync the data with backend so we should only update the Onyx data when the queue is empty
	if (!hasRemainingRequests) {
	Log.info('[SequentialQueue] Queue is empty, flushing Onyx updates');
	flushOnyxUpdatesQueue()?.then(() => {

The logs shared by dmkt9 show this sequence:

1. RevertSplitTransaction finishes and is removed from the queue.
2. OpenReport finishes and is removed from the queue.
3. ReadNewestAction becomes the ongoing request.
4. The queue does not log the normal Request processed successfully / next-request path until a UI interaction happens.

So the problem is not that the reverse-split destination is wrong, and it is not primarily the table/detail render decision. The expense mutation response data can already be available from the backend, but it remains buffered in the queued Onyx update path because SequentialQueue has not drained. While ReadNewestAction is stuck as the ongoing write, the RevertSplitTransaction / OpenReport Onyx updates are not allowed to reach the report/transaction keys, leaving the UI stale.

I am not relying on the unproven explanation that the iOS native networking layer definitely delivered the response but delayed the native-to-JS callback. The evidence we have is enough: at the JS queue level, the promise chain does not progress past ReadNewestAction, and the current flush policy lets that housekeeping write block previously completed mutation response data.

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

Make ReadNewestAction non-blocking with respect to queued mutation response data.

The narrowest fix is in src/libs/Network/SequentialQueue.ts: before starting a low-priority housekeeping write such as WRITE_COMMANDS.READ_NEWEST_ACTION, flush any already queued Onyx updates from previous completed writes when the remaining queue contains only non-mutating housekeeping requests. In this repro, that means the queued updates from RevertSplitTransaction / OpenReport can be applied before ReadNewestAction is allowed to become the user-visible blocker.

The important constraints are:

• Keep normal sequential ordering for real mutation writes.
• Do not flush queued server updates ahead of another pending mutating write.
• Use ReadNewestAction as the trigger, and allow PusherPing in the remaining low-priority tail because dmkt9's logs show PusherPing queued behind ReadNewestAction in the repro.
• Do not change reverse-split optimistic data, navigation, ReportActionsList, or shouldWaitForTransactions for this root cause.

A targeted queue helper would look conceptually like this:

const LOW_PRIORITY_NON_MUTATING_WRITES = new Set([WRITE_COMMANDS.READ_NEWEST_ACTION, WRITE_COMMANDS.PUSHER_PING]);

const shouldFlushBeforeProcessingRequest =
    requestToProcess.command === WRITE_COMMANDS.READ_NEWEST_ACTION &&
    !isEmpty() &&
    getAllPersistedRequests().every((request) => LOW_PRIORITY_NON_MUTATING_WRITES.has(request.command));

if (shouldFlushBeforeProcessingRequest) {
    await flushOnyxUpdatesQueue();
}

The exact implementation can be adjusted to match the existing queue style, but the behavior should be: a mark-read write must not keep settled expense mutation data buffered behind it.

What alternative solutions did you explore? (Optional)

I previously proposed filtering pending-delete transactions in ReportActionsList before calling shouldDisplayReportTableView. That can harden a downstream grouped-list vs single-expense detail decision, but it does not explain dmkt9's logs or the infinite hang because the data has not reliably reached Onyx yet.

I also considered changing shouldWaitForTransactions or setting report.total differently in the reverse-split optimistic data. Those are downstream fixes for stale or incomplete local data, but they do not address why the server response data from RevertSplitTransaction can remain buffered.

A broad iOS timer, global request watchdog, or native run-loop workaround would be riskier than needed for the first fix. The safer change is to prevent non-critical mark-read writes from blocking already completed mutation response updates.

[MobileMage]

Proposal

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

After deleting one split from the Edit Splits screen on iOS, the expense report page gets stuck on a full-screen loading indicator indefinitely. The screen only recovers after the user performs a swipe gesture.

What is the root cause of that problem?

SplitExpensePage uses isLoadingOnyxValue(draftTransactionMetadata) to determine whether to show a FullScreenLoadingIndicator. When removeSplitExpenseField is called (just before Navigation.goBack(backTo)), it calls Onyx.merge(...) on the draft transaction key. This merge operation momentarily resets the Onyx metadata status back to "loading" as Onyx processes the write. Navigation back to SplitExpensePage happens almost simultaneously, so the page mounts while draftTransactionMetadata.status === "loading" and renders the full-screen spinner. On iOS, the navigation animation apparently completes before Onyx settles the merge, leaving the loading indicator on screen with no subsequent state change to remove it — unless the user triggers a gesture that forces a re-render. On other platforms or under different timing, Onyx settles quickly enough that the spinner disappears on its own.

App/src/pages/iou/SplitExpensePage.tsx

Lines 493 to 504 in 9782e9e

	if (isLoadingDraftTransaction) {
	const reasonAttributes: SkeletonSpanReasonAttributes = {
	context: 'SplitExpensePage',
	isLoadingDraftTransaction,
	};
	return (
	<FullScreenLoadingIndicator
	style={[styles.opacity1]}
	reasonAttributes={reasonAttributes}
	/>
	);
	}

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

The loading guard in SplitExpensePage should not treat a transitional Onyx "loading" state as a reason to show the full-screen spinner when there is already a valid draftTransaction value present. The fix is to tighten the loading condition on line 94: only show the full-screen loading indicator when draftTransactionMetadata is in the "loading" status and draftTransaction is undefined (i.e., the data has never been loaded). Concretely, replace const isLoadingDraftTransaction = isLoadingOnyxValue(draftTransactionMetadata) with a check like const isLoadingDraftTransaction = isLoadingOnyxValue(draftTransactionMetadata) && draftTransaction === undefined. This way, if Onyx has previously delivered a value for the draft transaction and then briefly re-enters a loading state during a merge triggered by the split removal, the page will not regress to a spinner — it will continue rendering with the last-known value until Onyx settles the new one.

App/src/pages/iou/SplitExpensePage.tsx

Lines 93 to 94 in 9782e9e

	const [draftTransaction, draftTransactionMetadata] = useOnyx(`${ONYXKEYS.COLLECTION.SPLIT_TRANSACTION_DRAFT}${transactionID}`);
	const isLoadingDraftTransaction = isLoadingOnyxValue(draftTransactionMetadata);

What alternative solutions did you explore?

N/A

[melvin-bot]

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When a split expense is deleted, the app navigates back to the expense report screen. On iOS, this navigation likely triggers a state update that causes the report to re-render, but the loading indicator gets stuck because the screen doesn't receive a proper "loaded" signal after the navigation transition completes.

The root cause appears to be in how the report screen handles the loading state after a split deletion. When deleteSplit is called, the optimistic update modifies the transaction/report data, which triggers a re-render of the report. On iOS specifically, the FlatList or ScrollView inside the report screen doesn't re-render/scroll to reflect the new content because the loading state (isLoadingInitialReportActions or a similar flag) remains true until a scroll/swipe gesture forces a layout recalculation.

Looking at the report actions list component at:
https://github.com/Expensify/App/blob/main/src/components/ReportActionsList.tsx

And the report screen at:
https://github.com/Expensify/App/blob/main/src/pages/home/ReportScreen.tsx

The issue is likely that after navigation back to the report, the FlatList component has stale layout measurements on iOS. The swipe gesture that fixes it is essentially forcing a layout pass. This is a known iOS-specific behavior where FlatList with inverted prop doesn't re-measure properly after programmatic navigation.

The likely trigger is that after split deletion the report parentReportAction changes (the split expense is updated), causing ReportScreen to briefly show a loading spinner via shouldShowLoader — but on iOS the layout event that would dismiss it never fires unless the user interacts with the screen.

Looking at ReportScreen.tsx, the isLoadingInitialReportActions or isReportFullyVisible flag is likely the culprit — when navigating back after a delete, the screen mounts/updates but the onLayout callback for the message list isn't fired by iOS until a user gesture occurs.

The relevant loading logic is around:
https://github.com/Expensify/App/blob/main/src/pages/home/ReportScreen.tsx

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

I'd suggest ensuring that after navigating back to the report screen following a split deletion, we explicitly reset any loading/layout state that iOS may be holding onto. Specifically, in the ReportActionsList or ReportScreen, we should call scrollToIndex or trigger a layout flush when the component updates due to a navigation-back event.

The most targeted fix would be to add a key prop change or call flashScrollIndicators/force a layout update on the FlatList ref when the report's action count changes due to a deletion, particularly on iOS:

// In src/components/ReportActionsList.tsx (or equivalent)
  useEffect(() => {
+     if (reportActions.length > 0 && listRef.current) {
+         // Force layout recalculation on iOS after actions change (e.g. split deletion)
+         listRef.current.flashScrollIndicators();
+     }
  }, [reportActions.length]);

Alternatively, a more robust fix would be to ensure the onLayout handler in ReportScreen is explicitly called after a split deletion completes. In src/libs/actions/IOU.ts, after the deleteSplit API call updates Onyx with the new transaction state, we should navigate back with a param that signals to the report screen to re-initialize its layout:

// In src/libs/actions/IOU.ts, within the deleteSplit (or equivalent) function
  Navigation.goBack();
+ // Small timeout to allow navigation transition to complete before forcing layout
+ setTimeout(() => {
+     setIsReportFullyVisible(true);
+ }, 0);

Since that second approach is too coupled, the cleaner path is the first approach — watching reportActions.length in ReportActionsList and calling scrollToOffset({offset: 0, animated: false}) on the list ref to force iOS to re-measure the layout. This is a minimal, targeted iOS fix that doesn't affect Android or web behavior.

I'd also update src/pages/home/ReportScreen.tsx to pass a stable extraData prop to the list component that includes the action count, ensuring React Native's FlatList reconciler recognizes the data has changed and triggers a proper layout pass on iOS.

What alternative solutions did you explore? (Optional)

I considered adding removeClippedSubviews={false} to the FlatList on iOS, which sometimes resolves stuck rendering states, but this has performance implications for large report lists and doesn't address the root cause of the missing layout event.

I also considered wrapping the navigation call in InteractionManager.runAfterInteractions within the delete action, but this would only help if the issue is a race between the navigation transition and the Onyx update — the video suggests the screen is fully navigated back but still stuck, so the problem is post-navigation.