Update create transaction Manual flow to ask for merchant after asking for amount v3 by nkdengineer · Pull Request #82214 · Expensify/App

nkdengineer · 2026-02-12T03:18:36Z

Explanation of Change

Update create transaction Manual flow to ask for merchant after asking for amount

Fixed Issues

$ #76050
PROPOSAL: #76050 (comment)

Tests

Pre-requisites

Have at least one workspace with a policy expense chat
Have access to a personal (P2P) chat
Set up a default workspace in settings

Test Case 1: Manual Expense from Workspace Chat (Primary Flow)

Steps:

Open a workspace expense chat
Tap the + button in the composer
Select Create expense → Manual tab
Enter an amount (e.g., $50) and tap Next
Expected: You should be navigated to the Merchant step
Enter a merchant name and tap Save
Expected: You should be navigated to the Confirmation page
Tap the back button on the Confirmation page
Expected: You should go back to the Merchant page (not Amount)
Tap the back button on the Merchant page
Expected: You should go back to the Amount page
Enter an amount (e.g., $50) and tap Next
Expected: You should be navigated to the Confirmation page

Test Case 2: Global Create with Default Workspace

Steps:

Set a workspace as your default (Settings → Workspaces → select one as default)
Tap the global + button
Select Create expense → Manual tab
Enter an amount and tap Next
Expected: You should be navigated to the Merchant step
Enter a merchant and tap Save
Expected: You should be navigated to the Confirmation page
Tap the back button on the Confirmation page
Expected: You should go back to the Merchant page (not Amount)
Tap the back button on the Merchant page
Expected: You should go back to the Amount page
Enter an amount (e.g., $50) and tap Next
Expected: You should be navigated to the Confirmation page

Test Case 3: Global Create without Default Workspace (Participants Flow)

Steps:

Remove any default workspace or use an account with a personal policy only
From any screen, tap the global + button
Select Create expense → Manual tab
Enter an amount and tap Next
Expected: You should be navigated to the Participants step
Select a workspace expense chat as the participant
Tap Next
Expected: You should be navigated to the Merchant step
Enter a merchant and tap Save
Expected: You should be navigated to the Confirmation page
Verify back navigation (Confirmation → Merchant → Participants)

Test Case 4: P2P (Personal) Transaction – No Merchant Step

Steps:

Open a personal 1:1 chat (not a workspace chat)
Tap the + button
Select Create expense → Manual tab
Enter an amount and tap Next
Expected: You should be navigated directly to the Confirmation page (no Merchant step)

Test Case 5: Scan Request – No Merchant Step

Steps:

Open a workspace expense chat
Tap the + button
Select Create expense → Scan tab
Add a receipt
Expected: You should be navigated to the Confirmation page (no Merchant step before confirmation)
Repeat using the global + button → Participants → select a workspace
Expected: There should still be no Merchant step for scan requests

Test Case 6: Participants – Select Personal Chat (No Merchant Step)

Steps:

From global + → Create expense → Manual tab
Enter an amount and tap Next
On the Participants step, select a user (not a workspace)
Tap Next
Expected: You should be navigated directly to the Confirmation page (no Merchant step)

Test Case 7: Self DM Expense – Move to Workspace (Without Merchant)

Steps:

Go to your Self DM (personal chat with yourself)
Tap + → Create expense → Manual tab
Enter an amount and complete the expense (without merchant)
Tap it and choose Submit or Categorize to move it to a workspace
Select a workspace
Expected: You should be navigated to the Merchant step
Tap the back button on the merchant page
Expected: You should go back to the ** Participants** page
Select a P2P chat
Expected: You should be navigated to the Confirmation page
Tap the back button on the Confirmation page
Expected: You should go back to the Participants page (not Merchant)
Select a workspace
Expected: You should be navigated to the Merchant step

Test Case 8: Self DM Expense – Move to Workspace (With Merchant)

Steps:

Go to your Self DM (personal chat with yourself)
Tap + → Create expense → Manual tab
Enter an amount and complete the expense (with merchant)
Tap it and choose Submit or Categorize to move it to a workspace
Select a workspace
Expected: You should be navigated to the Confirmation page
Tap the back button on the Confirmation page
Expected: You should go back to the Participants page
Select a P2P chat
Expected: You should be navigated to the Confirmation page
Clear the merchant and tap Save
Tap the back button on the Confirmation page
Expected: You should go back to the Participants page
Select a workspace
Expected: You should be navigated to the Merchant step

Test Case 9: Track Expense from Workspace Chat and FAB (Both)

Steps:

Open a workspace expense chat
Tap the + button in the composer
Select Track expense → Map tab
Select waypoints and tap Next
Expected: You should be navigated to the Confirmation page

Test Case 10: Track Expense (Manual) from Workspace Chat and FAB (Both)

Steps:

Open a workspace expense chat
Tap the + button in the composer
Select Track expense → Manual tab
Enter distance and tap Next
Expected: You should be navigated to the Confirmation page

Per diem - Merchant field opens and can be edited when submitting from self DM #80291

Precondition:

Workspace has per diem rates.

Go to workspace chat.
Create a per diem expense.
Open the per diem expense.
Go to self DM.
Open the unreported per diem expense.
Click Report > Remove from report/
Click on the report header > Submit it to someone.
Select any participant
Verify that the merchant step isn't displayed

Merchant page does not open after entering amount when creating expense from empty report #80283

Go to workspace chat.
Create an empty report.
Open the empty report.
Click Add expense > Create expense > Manual.
Enter amount > Next.
Verify that the merchant page is displayed

Invoice - Merchant page opens when sending from FAB, but does not open when sending from invoice room #80284

Precondition:

User has received an invoice.

Open FAB > Send invoice.
Enter amount > Next.
Enter merchant > Next.
Select user.
On confirm page, click Send invoice.
On invoice room, click + > Send invoice.
Enter amount > Next.
Verify that the merchant step isn't displayed in both cases

Merchant page opens after selecting workspace chat when submitting distance expense #80280

Go to self DM.
Create a manual or map distance expense.
Click Submit it to someone.
Select workspace chat.
Verify that the merchant step isn't displayed

Expense - Merchant page opens when expense already has merchant when submitting expense #80279

Go to self DM.
Create a manual expense with merchant.
Click Submit it to someone.
Select workspace chat.
Verify that the merchant step isn't displayed.

Expense - App returns to merchant page after selecting a user on confirm page #80282

Precondition:

User has a workspace.

Open FAB > Create expense > Manual.
Enter amount > Next.
Enter merchant > Next.
On confirm page, click To field.
Select a user (not self DM).
Verify that the merchant step isn't displayed

Expense - Report auto opens when expense is created from report preview #82131

Go to workspace chat.
Create an empty report.
On the report preview, click Add expense > Create expense.
Create a manual expense.
Verify that the user stays on the workspace chat

Time - Confirm page opens instead of Merchant page after clearing merchant field #82107

Precondition:

Time tracking is enabled in the workspace.

Go to workspace chat.
Create a time expense.
Open the time expense.
Click Report > Remove from report.
Go to self DM.
Open the time expense.
Click on the header > Submit it to someone.
Enter email and select user.
On confirm page, click Merchant.
Clear the merchant and save it.
Click RHP back button.
Select workspace chat
Verify that the merchant step is opened

Verify that no errors appear in the JS console

Offline tests

Same

QA Steps

Same as test

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Screen.Recording.2025-12-03.at.15.27.09.mov

Android: mWeb Chrome

Screen.Recording.2025-12-03.at.15.26.38.mov

iOS: Native

Screen.Recording.2025-12-03.at.15.25.37.mov

iOS: mWeb Safari

Screen.Recording.2025-12-03.at.15.24.18.mov

MacOS: Chrome / Safari

Screen.Recording.2025-12-03.at.15.23.20.mov

Screen.Recording.2025-12-03.at.15.35.10.mov

Screen.Recording.2026-01-28.at.01.05.58.mov

Screen.Recording.2026-01-28.at.01.06.29.mov

Screen.Recording.2026-01-28.at.01.06.56.mov

Screen.Recording.2026-01-28.at.01.07.22.mov

Screen.Recording.2026-01-28.at.01.07.42.mov

Screen.Recording.2026-01-28.at.01.09.16.mov

Screen.Recording.2026-02-12.at.11.20.25.mov

Screen.Recording.2026-02-12.at.11.20.53.mov

… ask for merchant after asking for amount v2""

codecov · 2026-02-12T03:25:29Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
...rc/pages/iou/request/step/IOURequestStepAmount.tsx	`3.50% <0.00%> (-0.10%)`	⬇️
.../pages/iou/request/step/IOURequestStepMerchant.tsx	`0.00% <0.00%> (ø)`
src/ROUTES.ts	`12.80% <0.00%> (-0.06%)`	⬇️
src/libs/IOUUtils.ts	`73.86% <0.00%> (-3.52%)`	⬇️
...es/iou/request/step/IOURequestStepParticipants.tsx	`0.00% <0.00%> (ø)`
... and 14 files with indirect coverage changes

melvin-bot · 2026-02-12T04:30:14Z

@Krishna2323 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

melvin-bot · 2026-02-12T04:30:14Z

@Krishna2323 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

github-actions · 2026-02-12T04:31:54Z

src/pages/iou/request/step/IOURequestStepMerchant.tsx

+        if (isEditing) {
+            return isPolicyExpenseChat(report) || isExpenseRequest(report);
+        }
+        return transaction?.participants?.some((participant) => !!participant.isPolicyExpenseChat);


❌ PERF-6 (docs)

The useFocusEffect hook is resetting component state (isSaved and currentMerchant) based on props changing. This state can be derived directly from props instead of using an effect.

Suggested fix:
Remove the useFocusEffect and derive the state directly. The currentMerchant state can be initialized directly from initialMerchant without needing to reset it in an effect:

// Remove useFocusEffect - state will naturally reset when component remounts // The currentMerchant state is already initialized from initialMerchant const [currentMerchant, setCurrentMerchant] = useState(initialMerchant);

If you need to respond to prop changes, consider using the key prop pattern (see PERF-7) or compute values during render.

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:32:06Z

src/pages/iou/request/step/IOURequestStepMerchant.tsx


    const navigateBack = useCallback(() => {
        Navigation.goBack(backTo);
    }, [backTo]);


❌ PERF-6 (docs)

The navigation logic inside useEffect depends on multiple values (backTo, isEditing, backToReport) to determine where to navigate. This could be computed during the navigation action itself rather than in a useEffect that triggers after state changes.

Suggested fix:
Consider computing the navigation target at the point where setIsSaved(true) is called in the updateMerchant function, rather than relying on a useEffect to react to the isSaved state change:

const updateMerchant = (value: FormOnyxValues<typeof ONYXKEYS.FORMS.MONEY_REQUEST_MERCHANT_FORM>) => { const newMerchant = value.moneyRequestMerchant?.trim(); // ... existing validation logic ... // Compute navigation target directly const shouldNavigateToConfirmation = !isEditing && !backTo; if (shouldNavigateToConfirmation) { Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(action, iouType, transactionID, reportID, backToReport, undefined, Navigation.getActiveRoute())); } else { Navigation.goBack(backTo); } };

This eliminates the need for the isSaved state and the corresponding useEffect.

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:32:15Z

src/pages/iou/request/step/IOURequestStepParticipants.tsx

@@ -88,6 +89,7 @@ function IOURequestStepParticipants({

    // We need to set selectedReportID if user has navigated back from confirmation page and navigates to confirmation page with already selected participant
    const selectedReportID = useRef<string>(participants?.length === 1 ? (participants.at(0)?.reportID ?? reportID) : reportID);


❌ CONSISTENCY-4 (docs)

The selectedParticipants ref is created but only used once at line 341 to read the first participant. This ref is redundant since the same value can be accessed directly from the participants variable or the function parameter val in addParticipant.

Suggested fix:
Remove the selectedParticipants ref and use the existing participants prop or the val parameter directly:

// Remove line 91: // const selectedParticipants = useRef<Participant[]>(participants); // Remove line 226: // selectedParticipants.current = val; // At line 341, use val or participants directly: const firstParticipant = participants?.at(0); // or use _participants parameter if available

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:32:27Z

src/libs/IOUUtils.ts

+ * @param isEditingSplitBill - Whether this is editing a split bill
+ * @returns true if merchant is required and missing, false otherwise
+ */
+function shouldRequireMerchant(transaction: OnyxInputOrEntry<Transaction> | undefined, report: OnyxInputOrEntry<Report> | undefined, isEditingSplitBill = false): boolean {


❌ CONSISTENCY-6 (docs)

The shouldRequireMerchant function accesses properties from potentially undefined objects (transaction?.participants, report) without comprehensive null checks. While the function returns false for undefined transactions, it could still throw errors if transaction.participants is malformed.

Suggested fix:
Add defensive checks to handle edge cases:

function shouldRequireMerchant(transaction: OnyxInputOrEntry<Transaction> | undefined, report: OnyxInputOrEntry<Report> | undefined, isEditingSplitBill = false): boolean { if (\!transaction) { return false; } if (\!isMerchantMissing(transaction)) { return false; } // For scan requests, merchant is not required unless it's a split bill being edited if (isScanRequest(transaction) && \!isEditingSplitBill) { return false; } // Add defensive check for participants array const hasParticipantsWithPolicyExpenseChat = Array.isArray(transaction?.participants) && transaction.participants.some((participant) => \!\!participant?.isPolicyExpenseChat); // Check if merchant is required based on report type and participants return \!\!(isPolicyExpenseChatUtils(report) || isExpenseReport(report) || hasParticipantsWithPolicyExpenseChat); }

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:32:44Z

src/ROUTES.ts

            if (!transactionID || !reportID) {
                Log.warn('Invalid transactionID or reportID is used to build the MONEY_REQUEST_STEP_MERCHANT route');
            }



❌ CONSISTENCY-2 (docs)

The route generation logic constructs query parameters and paths manually using string concatenation. While functional, this approach is error-prone and makes it harder to understand the relationship between reportActionID and backToReport parameters.

Suggested fix:
Add comments to clarify the parameter precedence and construction logic:

// Build optional route segments: // 1. reportActionID is added as path segment (/:reportActionID) // 2. backToReport is added as query parameter (?backToReport=...) let optionalRoutePart = ""; if (reportActionID) { optionalRoutePart += `/${reportActionID}`; } if (backToReport) { optionalRoutePart += `?backToReport=${backToReport}`; }

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:32:57Z

src/pages/iou/request/step/IOURequestStepParticipants.tsx

                return;
            }

+            const firstParticipant = selectedParticipants.current?.at(0);


❌ PERF-2 (docs)

The merchant requirement check is performed after several expensive operations including setting transaction report, split shares, and other transaction manipulations. This check could be moved earlier to avoid unnecessary work.

Suggested fix:
Move the merchant requirement check before the expensive transaction operations:

const goToNextStep = useCallback( (_value?: string, _participants?: Participant[]) => { const isCategorizing = action === CONST.IOU.ACTION.CATEGORIZE; const isShareAction = action === CONST.IOU.ACTION.SHARE; // Check merchant requirement early const firstParticipant = _participants?.at(0) || participants?.at(0); const isMerchantRequired = \!\!firstParticipant?.isPolicyExpenseChat && isMerchantMissing(initialTransaction) && (iouRequestType === CONST.IOU.REQUEST_TYPE.MANUAL || (isMovingTransactionFromTrackExpense && iouRequestType === CONST.IOU.REQUEST_TYPE.TIME)); // ... rest of the logic }, // ... );

This avoids performing split share calculations and other operations when the user will immediately navigate to the merchant page.

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:33:09Z

src/pages/iou/request/step/IOURequestStepParticipants.tsx

            Performance.markStart(CONST.TIMING.OPEN_CREATE_EXPENSE_APPROVE);
            waitForKeyboardDismiss(() => {
                // If the backTo parameter is set, we should navigate back to the confirmation screen that is already on the stack.
                // We wrap navigation in setNavigationActionToMicrotaskQueue so that data loading in Onyx and navigation do not occur simultaneously, which resets the amount to 0.


❌ CONSISTENCY-6 (docs)

The navigation logic has complex conditional branching with multiple paths (backTo with/without isMerchantRequired, merchant step with forceReplace, etc.) but lacks error handling or validation for edge cases. If the navigation fails or produces unexpected states, there's no fallback.

Suggested fix:
Add validation and comments to clarify the navigation logic:

// Navigation logic: // 1. If merchant is required and backTo is set: go back first, then replace with merchant page // 2. If merchant is required without backTo: navigate to merchant page with forceReplace // 3. If merchant not required and backTo is set: go back to confirmation // 4. Otherwise: navigate normally to confirmation or category page if (backTo && !isMerchantRequired) { // We don't want to compare params because we just changed the participants. Navigation.goBack(route, {compareParams: false}); } else { // If the merchant step is required and the backTo parameter is set, we need to go back to the confirmation screen first if (isMerchantRequired && backTo) { Navigation.goBack(); } Navigation.navigate(route, {forceReplace: isMerchantRequired && !!backTo}); }

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:33:20Z

src/pages/iou/request/step/IOURequestStepAmount.tsx

                setSplitShares(transaction, amountInSmallestCurrencyUnits, selectedCurrency || CONST.CURRENCY.USD, participantAccountIDs);
            }
            setMoneyRequestParticipantsFromReport(transactionID, report, currentUserPersonalDetails.accountID).then(() => {
+                // If merchant is required and missing, navigate to merchant step first


❌ PERF-2 (docs)

The merchant requirement check at line 310 is performed AFTER calling setMoneyRequestParticipantsFromReport which is an expensive async operation. If merchant is required, the user immediately navigates away, making the confirmation page setup work unnecessary.

Suggested fix:
Check merchant requirement before the async operation:

// Check merchant requirement first to avoid unnecessary async work if (shouldRequireMerchant(transaction, report, isEditingSplitBill)) { Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_MERCHANT.getRoute(action, CONST.IOU.TYPE.SUBMIT, transactionID, reportID, undefined, reportActionID, backToReport)); return; } setMoneyRequestParticipantsFromReport(transactionID, report, currentUserPersonalDetails.accountID).then(() => { navigateToConfirmationPage(iouType, transactionID, reportID, backToReport); });

This avoids the async participant setup when it's not needed for the next screen.

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:33:37Z

src/pages/iou/request/step/IOURequestStepAmount.tsx

                setTransactionReport(transactionID, {reportID: transactionReportID}, true);
                setMoneyRequestParticipantsFromReport(transactionID, targetReport, currentUserPersonalDetails.accountID).then(() => {
-                    Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(CONST.IOU.ACTION.CREATE, iouTypeTrackOrSubmit, transactionID, targetReport?.reportID));
+                    if (transactionReportID === CONST.REPORT.UNREPORTED_REPORT_ID) {


❌ PERF-2 (docs)

The merchant requirement check at line 333 could be performed BEFORE calling setMoneyRequestParticipantsFromReport to avoid unnecessary async work when navigating to the merchant step.

Suggested fix:
Restructure the logic to check merchant requirement first:

const resetToDefaultWorkspace = () => { setTransactionReport(transactionID, {reportID: transactionReportID}, true); // Check if we need merchant step before expensive participant setup if (transactionReportID !== CONST.REPORT.UNREPORTED_REPORT_ID) { Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_MERCHANT.getRoute(action, CONST.IOU.TYPE.SUBMIT, transactionID, targetReport?.reportID, undefined, reportActionID)); return; } setMoneyRequestParticipantsFromReport(transactionID, targetReport, currentUserPersonalDetails.accountID).then(() => { Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(CONST.IOU.ACTION.CREATE, iouTypeTrackOrSubmit, transactionID, targetReport?.reportID)); }); };

This avoids the async participant operation when immediately navigating to the merchant step.

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

github-actions · 2026-02-12T04:33:46Z

src/pages/iou/request/step/IOURequestStepAmount.tsx

                const chatReportID = selectedReport?.chatReportID ?? selectedReport?.reportID;

                Navigation.setNavigationActionToMicrotaskQueue(() => {
+                    if (shouldRequireMerchant(transaction, selectedReport, isEditingSplitBill)) {


❌ PERF-2 (docs)

The merchant requirement check at line 359 is performed AFTER calling setNavigationActionToMicrotaskQueue and setting up the confirmation route. If merchant is required, this setup work is wasted since navigation immediately changes direction.

Suggested fix:
Check merchant requirement before queuing navigation work:

if (shouldRequireMerchant(transaction, selectedReport, isEditingSplitBill)) { Navigation.setNavigationActionToMicrotaskQueue(() => { Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_MERCHANT.getRoute(CONST.IOU.ACTION.CREATE, navigationIOUType, transactionID, chatReportID, undefined, reportActionID)); }); return; } Navigation.setNavigationActionToMicrotaskQueue(() => { Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(CONST.IOU.ACTION.CREATE, navigationIOUType, transactionID, chatReportID)); });

This avoids setting up navigation to the confirmation page when the merchant page is the actual target.

Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ded42d973a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-02-12T04:45:22Z

src/pages/iou/request/step/IOURequestStepAmount.tsx

+                        Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(CONST.IOU.ACTION.CREATE, iouTypeTrackOrSubmit, transactionID, targetReport?.reportID));
+                        return;
+                    }
+                    Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_MERCHANT.getRoute(action, CONST.IOU.TYPE.SUBMIT, transactionID, targetReport?.reportID, undefined, reportActionID));


Gate default-workspace merchant redirect on requirement

This branch now always sends users to the merchant step whenever transactionReportID is not UNREPORTED, even though the transaction can already have a valid merchant (for example after returning from confirmation and being reset from a P2P selection due to a negative amount). In that case we should go straight back to confirmation, but this unconditional redirect reintroduces a redundant merchant step and inconsistent back navigation. Reuse shouldRequireMerchant(...) here before deciding the route.

Useful? React with 👍 / 👎.

Krishna2323 · 2026-02-13T20:59:38Z

@nkdengineer could you please review the AI review comments? Thanks!

Okay, lets put this on hold for this discussion.

Krishna2323 · 2026-03-03T17:25:37Z

@nkdengineer please close this PR.

Revert "[CP Staging] Revert "Update create transaction Manual flow to…

a688381

… ask for merchant after asking for amount v2""

melvin-bot bot assigned nkdengineer Feb 12, 2026

fix related regressions

ded42d9

nkdengineer marked this pull request as ready for review February 12, 2026 04:30

nkdengineer requested review from a team as code owners February 12, 2026 04:30

melvin-bot bot requested a review from Krishna2323 February 12, 2026 04:30

melvin-bot bot requested review from heyjennahay and removed request for a team February 12, 2026 04:30

github-actions bot reviewed Feb 12, 2026

View reviewed changes

chatgpt-codex-connector bot reviewed Feb 12, 2026

View reviewed changes

nkdengineer closed this Mar 3, 2026

		@@ -88,6 +89,7 @@ function IOURequestStepParticipants({

		// We need to set selectedReportID if user has navigated back from confirmation page and navigates to confirmation page with already selected participant
		const selectedReportID = useRef<string>(participants?.length === 1 ? (participants.at(0)?.reportID ?? reportID) : reportID);

Conversation

nkdengineer commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Pre-requisites

Test Case 1: Manual Expense from Workspace Chat (Primary Flow)

Test Case 2: Global Create with Default Workspace

Test Case 3: Global Create without Default Workspace (Participants Flow)

Test Case 4: P2P (Personal) Transaction – No Merchant Step

Test Case 5: Scan Request – No Merchant Step

Test Case 6: Participants – Select Personal Chat (No Merchant Step)

Test Case 7: Self DM Expense – Move to Workspace (Without Merchant)

Test Case 8: Self DM Expense – Move to Workspace (With Merchant)

Test Case 9: Track Expense from Workspace Chat and FAB (Both)

Test Case 10: Track Expense (Manual) from Workspace Chat and FAB (Both)

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

codecov bot commented Feb 12, 2026 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

melvin-bot bot commented Feb 12, 2026

Uh oh!

melvin-bot bot commented Feb 12, 2026

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ PERF-6 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ PERF-6 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ CONSISTENCY-4 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ CONSISTENCY-6 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ CONSISTENCY-2 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ PERF-2 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ CONSISTENCY-6 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ PERF-2 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ PERF-2 (docs)

Uh oh!

github-actions bot Feb 12, 2026

Choose a reason for hiding this comment

❌ PERF-2 (docs)

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

Krishna2323 commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nkdengineer commented Feb 12, 2026 •

edited

Loading

codecov bot commented Feb 12, 2026 •

edited by github-actions bot

Loading

Krishna2323 commented Feb 13, 2026 •

edited

Loading