Create expense from QAB after split expense, Confirm page loads infinitely

[jponikarchuk]

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.41-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84601
Email or phone of affected tester (no customers): lekima20+622103@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 16 pro/ 26.3
App Component: Money Requests

Action Performed:

1. Open app
2. Create expense via global (+) > Create expense > Manual tab > enter amount > select workspace > create expense
3. Create expense via global (+) > Create expense > Scan tab > scan receipt > create expense
4. Edit an existing expense amount, verify edit saves correctly
5. Tap on the edited expense at step 4 > More > Split > Save
6. Tap back button to return Inbox
7. Tap Create expense at Quick action and create a manual expense

Expected Result:

User can create expense from QAB

Actual Result:

Create expense from QAB, confirm page loads infinitely

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[wildan-m]

Proposal

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

After performing "More > Split > Save" on an existing expense, tapping the Quick Action Button (QAB) to create a new expense causes the confirmation page to load indefinitely. The user cannot complete the expense creation flow.

What is the root cause of that problem?

When the user saves a split via "More > Split > Save", updateSplitTransactions iterates over each child transaction and calls getMoneyRequestInformation for each one. This flows into buildOnyxDataForMoneyRequest, which unconditionally overwrites NVP_QUICK_ACTION_GLOBAL_CREATE with a REQUEST_MANUAL action type and the split context's chatReportID (a policy expense chat):

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

Lines 2458 to 2467 in 693f7f5

	if (!isOneOnOneSplit) {
	onyxData.optimisticData?.push({
	onyxMethod: Onyx.METHOD.SET,
	key: ONYXKEYS.NVP_QUICK_ACTION_GLOBAL_CREATE,
	value: {
	action: newQuickAction,
	chatReportID: chat.report?.reportID,
	isFirstQuickAction: isEmptyObject(quickAction),
	},
	});

The guard if (!isOneOnOneSplit) is meant to skip this update in split flows, but isOneOnOneSplit defaults to false in buildOnyxDataForMoneyRequest:

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

Line 1906 in 693f7f5

isOneOnOneSplit = false,

The initial split creation path (splitBill) correctly passes isOneOnOneSplit: true directly:

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

Lines 7494 to 7497 in 693f7f5

	} = buildOnyxDataForMoneyRequest({
	isNewChatReport: isNewOneOnOneChatReport,
	shouldCreateNewMoneyRequestReport: shouldCreateNewOneOnOneIOUReport,
	isOneOnOneSplit: true,

However, the split update path (updateSplitTransactions) goes through getMoneyRequestInformation, which does NOT forward the flag — even though isSplitExpense: true is already passed:

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

Lines 1251 to 1272 in 693f7f5

	} = getMoneyRequestInformation({
	participantParams,
	parentChatReport,
	policyParams,
	transactionParams,
	moneyRequestReportID: splitExpense?.reportID,
	existingTransaction,
	existingTransactionID,
	newReportTotal: reportTotals.get(splitExpense?.reportID ?? String(CONST.DEFAULT_NUMBER_ID)) ?? 0,
	newNonReimbursableTotal: (transactionReport?.nonReimbursableTotal ?? 0) - changesInReportTotal,
	isSplitExpense: true,
	currentReportActionID: !isReverseSplitOperation ? currentReportAction?.reportActionID : undefined,
	isASAPSubmitBetaEnabled,
	currentUserAccountIDParam: currentUserPersonalDetails?.accountID,
	currentUserEmailParam: currentUserPersonalDetails?.login ?? '',
	transactionViolations,
	quickAction,
	shouldGenerateTransactionThreadReport: !isReverseSplitOperation,
	policyRecentlyUsedCurrencies,
	betas,
	personalDetails,
	});

Inside getMoneyRequestInformation, the call to buildOnyxDataForMoneyRequest at line 3618 omits isOneOnOneSplit, so it defaults to false and the quick action is overwritten:

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

Lines 3618 to 3661 in 693f7f5

	const {optimisticData, successData, failureData} = buildOnyxDataForMoneyRequest({
	participant,
	isNewChatReport,
	shouldCreateNewMoneyRequestReport,
	shouldGenerateTransactionThreadReport,
	policyParams: {
	policy,
	policyCategories,
	policyTagList,
	},
	optimisticParams: {
	chat: {
	report: chatReport,
	createdAction: optimisticCreatedActionForChat,
	reportPreviewAction,
	},
	iou: {
	report: iouReport,
	createdAction: optimisticCreatedActionForIOUReport,
	action: iouAction,
	},
	transactionParams: {
	transaction: optimisticTransaction,
	transactionThreadReport: optimisticTransactionThread,
	transactionThreadCreatedReportAction: optimisticCreatedActionForTransactionThread,
	},
	policyRecentlyUsed: {
	categories: optimisticPolicyRecentlyUsedCategories,
	tags: optimisticPolicyRecentlyUsedTags,
	currencies: optimisticPolicyRecentlyUsedCurrencies,
	},
	personalDetailListAction: optimisticPersonalDetailListAction,
	nextStepDeprecated: optimisticNextStepDeprecated,
	nextStep: optimisticNextStep,
	testDriveCommentReportActionID,
	},
	retryParams,
	isASAPSubmitBetaEnabled,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	quickAction,
	personalDetails,
	});

After the split, the corrupted quick action has action: REQUEST_MANUAL with a chatReportID pointing to a policy expense chat. When the user taps QAB, the amount step's shouldSkipConfirmation evaluates to false (because isPolicyExpenseChat(report) is true), sending the user to the confirmation page. But the transaction and report context set up through this corrupted path doesn't match what the confirmation page expects, causing it to not render properly.

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

Thread the existing isSplitExpense parameter through getMoneyRequestInformation to buildOnyxDataForMoneyRequest as isOneOnOneSplit. This is a one-line addition — pass isOneOnOneSplit: isSplitExpense in the buildOnyxDataForMoneyRequest call inside getMoneyRequestInformation. Since isSplitExpense is only true when called from updateSplitTransactions, this prevents the quick action from being overwritten during split edits while leaving all other paths unchanged.

https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/85932-fix-qab-after-split?expand=1

[melvin-bot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!