[Due for payment 2025-07-04] [$250] QAB - Create the first expense after logging in missing the amount, merchant, and date

[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.1.45-6
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/6101487
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Windows 10 / Chrome
App Component: Money Requests

Action Performed:

Precondition: The user has submitted a manual expense to the Workspace chat and logged out

1. Log in to New Dot
2. Click on the FAB and select the QAB button (Manual expense)
3. Enter the amount
4. Click on the Next button
5. Click on the Create expense
6. Click on the new report after creating

Expected Result:

The first expense from the QAB has the amount, merchant, and date

Actual Result:

After logging in back, the first expense from the QAB is missing the amount, merchant, and date

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021922533019675558969
• Upwork Job ID: 1922533019675558969
• Last Price Increase: 2025-05-21
• Automatic offers:
• dominictb | Reviewer | 107408265

Issue Owner

Current Issue Owner: @jliexpensify

[melvin-bot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[melvin-bot]

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

[jliexpensify]

I actually cannot repro this on a Pixel 7 (v9.1.45-6). After creating the first expense, I logged out and logged back in and that expense actually disappeared for me which is really strange.

@dominictb any luck repro-ing on your side?

[bernhardoj]

Proposal

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

When creating expense from QAB after re-login, some fields are missing.

What is the root cause of that problem?

Some fields such as amount are missing because shouldShowSmartScanFields is false.

App/src/components/MoneyRequestConfirmationListFooter.tsx

Line 379 in 23537ae

shouldShow: shouldShowSmartScanFields && shouldShowAmountField,

shouldShowSmartScanFields is false if the request type is SCAN, even though the QAB action is MANUAL. This happens because of the wrong data initialization. In IOU page, we have 2 logic to initialize or reinitialize the money request data.

This is triggered whenever the current transaction draft reportID is different from the reportID params, which is true too when we open the page for the first time.

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 75 to 83 in 28bc7b2

	useFocusEffect(
	useCallback(() => {
	// The test transaction can change the reportID of the transaction on the flow so we should prevent the reportID from being reverted again.
	if (transaction?.reportID === reportID || isLoadingSelectedTab || prevTransactionReportID !== transaction?.reportID) {
	return;
	}
	initMoneyRequest(reportID, policy, isFromGlobalCreate, transaction?.iouRequestType, transactionRequestType);
	}, [transaction, policy, reportID, isFromGlobalCreate, transactionRequestType, isLoadingSelectedTab, prevTransactionReportID]),
	);

This is triggered whenever the tab is changed, but also when the selectedTab onyx data is not available yet, which happens after we re-login.

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 93 to 101 in 28bc7b2

	const resetIOUTypeIfChanged = useCallback(
	(newIOUType: IOURequestType) => {
	if (transaction?.iouRequestType === newIOUType) {
	return;
	}
	initMoneyRequest(reportID, policy, isFromGlobalCreate, transaction?.iouRequestType, newIOUType);
	},
	[policy, reportID, isFromGlobalCreate, transaction],
	);

initMoneyRequest accepts old and new request type params. For resetIOUTypeIfChanged, the old one is undefined, while the new one is MANUAL, based on the route that we navigate to.

For the useFocusEffect, the old one is also undefined, while the new one is SCAN. This is the culprit. Why SCAN? As mentioned before, selectedTab isn't available after we re-login, and we set the default value to SCAN.

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 67 to 70 in 28bc7b2

	const transactionRequestType = useMemo(
	() => (transaction?.iouRequestType ?? shouldUseTab ? selectedTab : CONST.IOU.REQUEST_TYPE.MANUAL),
	[transaction?.iouRequestType, shouldUseTab, selectedTab],
	);

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 51 in 28bc7b2

const [selectedTab = CONST.TAB_REQUEST.SCAN, selectedTabResult] = useOnyx(`${ONYXKEYS.COLLECTION.SELECTED_TAB}${CONST.TAB.IOU_REQUEST_TYPE}`, {canBeMissing: true});

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

First, remove the default selectedTab value.

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 51 in 28bc7b2

const [selectedTab = CONST.TAB_REQUEST.SCAN, selectedTabResult] = useOnyx(`${ONYXKEYS.COLLECTION.SELECTED_TAB}${CONST.TAB.IOU_REQUEST_TYPE}`, {canBeMissing: true});

Then, avoid calling the initMoneyRequest here when the selectedTab is undefined. We can do it by adding the check to isLoadingSelectedTab.

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 75 to 83 in 28bc7b2

	useFocusEffect(
	useCallback(() => {
	// The test transaction can change the reportID of the transaction on the flow so we should prevent the reportID from being reverted again.
	if (transaction?.reportID === reportID || isLoadingSelectedTab || prevTransactionReportID !== transaction?.reportID) {
	return;
	}
	initMoneyRequest(reportID, policy, isFromGlobalCreate, transaction?.iouRequestType, transactionRequestType);
	}, [transaction, policy, reportID, isFromGlobalCreate, transactionRequestType, isLoadingSelectedTab, prevTransactionReportID]),
	);

selectedTab will always available after we open the page. This way, the logic above won't be triggered when selectedTab isn't available yet, and will be handled instead by resetIOUTypeIfChanged. This will eliminate 2 initMoneyRequest calls when selectedTab isn't available yet.

If selectedTab is available, then only the initMoneyRequest from the useFocusEffect is called.

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

N/A

[phuchoang23]

Proposal

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

Some data are missing after created expense

What is the root cause of that problem?

Currently, we have two required fields: Merchant and Category. However, only the validation for Merchant is implemented and working. Since we haven’t added validation for Category, it’s possible to create an expense without selecting a category, which is why some data is missing.

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

To solve this problem, we should add category validation similar to how we handle Merchant validation

App/src/components/MoneyRequestConfirmationListFooter.tsx

Lines 464 to 484 in c9bdbb1

	<MenuItemWithTopDescription
	key={translate('common.merchant')}
	shouldShowRightIcon={!isReadOnly}
	title={isMerchantEmpty ? '' : iouMerchant}
	description={translate('common.merchant')}
	style={[styles.moneyRequestMenuItem]}
	titleStyle={styles.flex1}
	onPress={() => {
	if (!transactionID) {
	return;
	}
	Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_MERCHANT.getRoute(action, iouType, transactionID, reportID, Navigation.getActiveRoute()));
	}}
	disabled={didConfirm}
	interactive={!isReadOnly}
	brickRoadIndicator={shouldDisplayMerchantError ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined}
	errorText={shouldDisplayMerchantError ? translate('common.error.fieldRequired') : ''}
	rightLabel={isMerchantRequired && !shouldDisplayMerchantError ? translate('common.required') : ''}
	numberOfLinesTitle={2}
	/>

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

N/A

[nkgupta-coder]

Proposal

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

[$250] QAB - Create the first expense after logging in missing the amount, merchant, and date fields.

What is the root cause of that problem?

The root cause is a mismatch between the transaction's iouRequestType and the actual transactionRequestType when a user logs in and tries to create their first expense.

Specifically, fields such as amount, merchant, and date are missing because the flags shouldShowSmartScanFields, shouldShowMerchant, and shouldShowDate are all false. This occurs because:

1. shouldShowSmartScanFields is false if the transaction.iouRequestType is SCAN, even though the QAB action might be MANUAL.

2. When a user logs in, transaction is initially undefined, but the default value for transactionRequestType is set to SCAN.

3. When the user clicks "Create an expense", a transaction is created with a default amount of 0 and transaction.iouRequestType is set to SCAN.

4. The critical issue occurs when the transactionRequestType value changes from SCAN to MANUAL - this change is not reflected in transaction.iouRequestType, which remains as SCAN.

5. This discrepancy between transactionRequestType (MANUAL) and transaction.iouRequestType (SCAN) causes the condition check in the useFocusEffect to fail, preventing the proper initialization of the expense form fields.

The problematic useFocusEffect code:
https://github.com/Expensify/App/blob/main/src/pages/iou/request/IOURequestStartPage.tsx#L75

useFocusEffect(
    useCallback(() => {
        // The test transaction can change the reportID of the transaction on the flow so we should prevent the reportID from being reverted again.
        if (transaction?.reportID === reportID || isLoadingSelectedTab || prevTransactionReportID !== transaction?.reportID) {
            return;
        }
        initMoneyRequest(reportID, policy, isFromGlobalCreate, transaction?.iouRequestType, transactionRequestType);
    }, [transaction, policy, reportID, isFromGlobalCreate, transactionRequestType, isLoadingSelectedTab, prevTransactionReportID]),
);

This function is meant to initialize or reinitialize the money request data when necessary, but the condition for skipping reinitialization doesn't account for changes in the request type.

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

We need to modify the condition in useFocusEffect to also check if the transaction's iouRequestType matches the current transactionRequestType. This ensures that the money request is reinitialized when the request type changes, particularly when switching from SCAN to MANUAL:

useFocusEffect(
    useCallback(() => {
        // The test transaction can change the reportID of the transaction on the flow so we should prevent the reportID from being reverted again.
        if ((transaction?.reportID === reportID && transactionRequestType === transaction?.iouRequestType) || isLoadingSelectedTab || prevTransactionReportID !== transaction?.reportID) {
            return;
        }
        initMoneyRequest(reportID, policy, isFromGlobalCreate, transaction?.iouRequestType, transactionRequestType);
    }, [transaction, policy, reportID, isFromGlobalCreate, transactionRequestType, isLoadingSelectedTab, prevTransactionReportID]),
);

useEffect(() => {
    Performance.markEnd(CONST.TIMING.OPEN_CREATE_EXPENSE);
}, []);

The key change is the addition of && transactionRequestType === transaction?.iouRequestType to the first condition. This ensures that if the request types don't match, the money request will be reinitialized with the correct type, properly setting up all the necessary fields for expense creation including amount, merchant, and date.

This fix addresses the specific sequence of events after login when:

1. The user logs in (transaction is undefined)
2. The default transactionRequestType is SCAN
3. The user clicks "Create an expense"
4. A transaction is created with iouRequestType as SCAN
5. The user selects MANUAL expense creation
6. Our fix ensures reinitialization happens properly with the new MANUAL type

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

To prevent reintroducing this issue, we should implement the following test scenarios:

1. Test creating the first expense after logging in, verifying that all fields (amount, merchant, date) are properly displayed.

2. Test the transition from SCAN to MANUAL mode, ensuring that all required fields are visible and properly initialized.

3. Test that initMoneyRequest is called when transactionRequestType changes, even if the report ID remains the same.

4. Test the behavior when transaction is undefined (simulating a fresh login), ensuring the form is properly initialized when the user tries to create an expense.

5. Test switching between different expense creation modes (SCAN, MANUAL, DISTANCE) and verify that fields are properly updated.

6. Test the edge case where a user logs in, navigates away from the expense creation screen, and then returns to create an expense.

7. Test with different network conditions to ensure that field initialization works correctly even if there are delays in retrieving user or policy data.

What alternative solutions did you explore? (Optional)

Before arriving at the proposed solution, I explored several alternative approaches:

1. Creating a separate initialization function specifically for handling the post-login scenario, which would always force a full reinitialization. This would work but would duplicate logic and potentially cause unnecessary reinitializations in other scenarios.

2. Adding an explicit check for undefined transaction in the component rendering logic to ensure fields are always shown in the initial state. This would mask the symptom but not address the root cause of the initialization issue.

3. Changing the default value of transactionRequestType to MANUAL when creating an expense via QAB. While this would work for this specific flow, it might cause inconsistencies in other parts of the application that expect the default to be SCAN.

4. Setting up a more comprehensive state management approach for the expense creation flow that keeps transactionRequestType and transaction.iouRequestType in sync at all times. This would be more robust but would require more extensive changes to the codebase.

The proposed solution is the most targeted approach that addresses the specific issue with minimal changes to the existing architecture.

[melvin-bot]

@dominictb Huh... This is 4 days overdue. Who can take care of this?