refactor: Remove shouldHandleNavigation from requestMoney and trackExpense

[TaduJR]

Explanation of Change

This is PR 3 + 4 of the incremental refactor for #84631 — moving navigation handling out of the IOU action layer. It covers requestMoney and trackExpense (PRs 1–2 are merged; createDistanceRequest, splitBill, sendInvoice, etc. follow in PRs 5–9). PRs 3 and 4 are combined because the action/navigation/deferred-write changes are mechanically interdependent — splitting them would produce a non-shippable intermediate state.

Problem: requestMoney / trackExpense took a shouldHandleNavigation boolean and performed their own post-creation navigation (modal dismiss, route reveal, draft cleanup). Per the issue, actions should only make API requests and Onyx writes — navigation belongs in the calling view.

Actions are now navigation-free

• requestMoney and trackExpense no longer navigate. shouldHandleNavigation, backToReport, and the deferred-write boolean are removed from both functions and from RequestMoneyInformation / CreateTrackExpenseParams.
• requestMoney keeps only its existing {iouReport} return (the confirmation batch loop threads it across iterations); trackExpense is now void. No callbacks or navigation payloads.
• createTransaction is a pure batch-writer over requestMoney / trackExpense.
• handleMoneyRequestStepScanParticipants / handleMoneyRequestStepDistanceNavigation — the orchestrators that branch on flow state and navigate — are relocated out of src/libs/actions/IOU/MoneyRequest.ts into the UI (src/pages/iou/request/step/…). MoneyRequest.ts now exports only pure write/Onyx primitives.
• submitPerDiemExpenseForSelfDM no longer performs its own self-DM navigation — the UI threads the optimistic chat id and navigates.

Navigation now lives in the view layer

• Post-create cleanup + navigation run through dedicated view-layer helpers in src/libs/Navigation/helpers/: cleanupAfterExpenseCreate, cleanupAndNavigateAfterExpenseCreate, and cleanupAfterSkipConfirmSubmit. The UI calls these directly after the action returns.
• submitWithDismissFirst (dismiss-first orchestration for skip-confirmation flows) is relocated to the view layer and is never imported from src/libs/actions/.
• The confirmation flow (useExpenseSubmission) assembles navigation data itself and runs performPostBatchCleanup after its write loop; the skip-confirm flows (scan / distance / amount) do the equivalent through the relocated handlers.

Correctness

• The UI pre-generates optimisticTransactionID and threads the same id into both the action and the post-create cleanup, so navigation and Search-highlight target the transaction the action actually writes.
• Move-from-track batches that would bail mid-write on malformed input are rejected up front, so expense drafts aren't leaked.

Fixed Issues

$ #84631
PROPOSAL: #84631 (comment)

Tests

Tests

This PR moves post-create navigation and cleanup out of the IOU action layer into the UI. Testing focuses on what happens right after an expense is submitted.

Core checks — verify all six after every test below:

• a. The expense is created and visible in the destination report.
• b. You land on the correct destination report.
• c. The modal/RHP dismisses cleanly — no flicker, no flash of the previous screen, no double-navigation.
• d. Drafts are cleared — start another expense of the same type and confirm every field is blank.
• e. The created expense is correct (amount, merchant, participant, receipt, category).
• f. For global-create flows, the just-created expense is highlighted and scrolled into view when the destination report opens — on the correct row, with no stale or phantom highlight.

Start context: run Tests 1–10 from each starting point, since navigation differs:

• (i) From inside an existing chat (land on that chat).
• (ii) From the Global Create "+" (land on the resolved/created chat).
• (iii) With the Search tab active (stay on Search; the expense appears in Search results).
• (iv) From a screen that is neither the Inbox nor Search (e.g. Settings, Workspaces) → after submit you land on Search and the skeleton→content transition must not jank.

A. Confirmation-screen flows

Test 1 — Manual expense

1. Tap the Global Create "+" button.
2. Select Create expense.
3. Enter an amount and tap Next.
4. Select a participant.
5. On the Confirmation screen, tap Create expense.
6. Verify the core checks (a–f).

Test 2 — Scan expense

1. Tap Global Create "+" → Create expense → Scan tab.
2. Take a photo of a receipt, or upload a receipt image.
3. Proceed to the Confirmation screen.
4. Tap Create expense.
5. Verify the core checks (a–f).

Test 3 — Distance expense (waypoint / map)

1. Tap Global Create "+" → Create expense → Distance tab.
2. Set a start and a stop waypoint on the map.
3. Tap Next.
4. On the Confirmation screen, tap Create expense.
5. Verify the core checks (a–f).

Test 4 — Distance expense (manual)

1. Tap Global Create "+" → Create expense → Distance → Manual.
2. Type a distance value.
3. Tap Next.
4. On the Confirmation screen, tap Create expense.
5. Verify the core checks (a–f).

Test 5 — Distance expense (odometer)

1. Tap Global Create "+" → Create expense → Distance → Odometer.
2. Enter a start reading and an end reading.
3. Tap Next.
4. On the Confirmation screen, tap Create expense.
5. Verify the core checks (a–f).

Test 6 — Distance expense (GPS) (iOS / Android only)

1. Tap Global Create "+" → Create expense → Distance → GPS.
2. Tap Start, move a short distance, then tap Stop.
3. Tap Next.
4. On the Confirmation screen, tap Create expense.
5. Verify the core checks (a–f).

Test 7 — Per-diem expense

1. Tap Global Create "+" → Per-diem.
2. Pick a per-diem-enabled workspace.
3. Set the dates and destination.
4. On the Confirmation screen, tap Create expense.
5. Verify you land on the workspace expense chat.
6. Verify the core checks (a–f).

B. Skip-confirmation (Quick Action) flows

Setup: create one expense of the type first. The Global Create "+" then shows a one-tap quick-action shortcut (e.g. "Scan receipt for [name]"). Using it skips the confirmation screen.

Test 8 — Quick-action manual amount

1. Tap Global Create "+" and select the quick-action shortcut.
2. Enter an amount and submit.
3. Verify no confirmation screen is shown.
4. Verify the core checks (a–f).

Test 9 — Quick-action scan

1. Tap Global Create "+" and select the scan quick-action shortcut.
2. Capture or upload a receipt.
3. Verify it submits directly with no confirmation screen.
4. Verify the core checks (a–f).

Test 10 — Quick-action distance (repeat for manual, odometer, and GPS-native)

1. Tap Global Create "+" and select the distance quick-action shortcut.
2. Enter the distance for the variant under test.
3. Submit.
4. Verify no confirmation screen is shown.
5. For odometer and GPS-native specifically: verify the modal dismisses, drafts clear, and you land on the destination chat.
6. Verify the core checks (a–f).

C. Multi-expense, split, send-money

Test 11 — Multi-receipt batch scan (iOS / Android)

1. Open the Scan screen and enable multi-scan.
2. Capture several receipts.
3. Tap Submit.
4. Verify all expenses are created and you navigate once, after the whole batch completes.
5. Verify all drafts clear (core checks a–f).

Test 12 — Split expense

1. Test split with a receipt from Global Create.
2. Test splitting a manual amount inside an existing group chat.
3. Test split from Global Create to several people.
4. For each, verify you land on the correct (existing or new) group chat.
5. Verify the core checks (a–f).

Test 13 — Send money / Pay

1. Start a pay flow from the amount step and, separately, from the Confirmation screen.
2. Pay a participant via Pay elsewhere.
3. Repeat using Pay with Expensify wallet.
4. Verify you land in the 1:1 chat with the payment visible.
5. Verify the core checks (a–f).

D. Track expense & moving a tracked expense

Test 14 — Track expense → self-DM

1. Tap Global Create "+" → Track expense.
2. Fill in the details and tap Create expense.
3. Verify it lands on your self-DM.
4. Repeat using the track quick-action from Global Create and verify it lands on the self-DM.
5. Verify the core checks (a–f).

Test 15 — Move a tracked expense

1. Open a tracked expense in your self-DM.
2. Tap Submit it, pick a destination participant/workspace, and confirm.
3. Verify you land on the destination participant/workspace chat — NOT the self-DM — the expense is gone from the self-DM, and the moved expense is highlighted in the destination chat.
4. Repeat step 2–3 for Categorize it and Share it.
5. Verify the core checks (a–f).

E. Share extension & layout

Test 16 — Share a file into Expensify (iOS / Android)

1. From another app, share an image/PDF to Expensify.
2. On the Submit details screen, pick a participant and tap Submit.
3. Verify you land on that participant's chat with the receipt.
4. Repeat steps 1–2 picking yourself and verify you land on the self-DM.
5. Verify the core checks (a–f).

F. Targeted regression checks

Test 17 — Nav-target & highlight regressions

1. Submit a tracked expense from the self-DM to another person → verify you land on that person's chat, not the self-DM.
2. From Global Create, scan an expense for a brand-new contact (no existing chat) → verify you land on the newly created 1:1 chat, not a blank screen or the Inbox.
3. Run track skip-confirmation from Global Create → verify you land on the created self-DM.
4. Move a tracked expense (Submit / Categorize / Share) → verify the destination report highlights the moved expense — the correct row, not a phantom or older one.
5. Global-create scan or track to a brand-new contact, or to a fresh (uncached) self-DM → verify the new chat highlights the new expense on first load.
6. Global-create submit from a screen that is neither the Inbox nor Search (e.g. Settings) → verify you land on Search and the skeleton→content transition is smooth, with no jank or hang.

G. Offline

Test 18 — Offline creation & sync

1. Go offline.
2. Run Tests 1, 2, 3, and 14 — verify the expense appears optimistically and navigation behaves identically.
3. Go back online.
4. Verify each expense syncs with no duplicate and no extra navigation.

• Verify that no errors appear in the JS console

Offline tests

Same as tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."
Same as tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified there are no new alerts related to the canBeMissing param for useOnyx
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Mac-Chrome.mp4

[melvin-bot]

@linhvovan29546 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]

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a063caf466

ℹ️ 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".

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
.../components/MoneyRequestHeaderSecondaryActions.tsx	0.53% <ø> (+<0.01%)	⬆️
src/hooks/useBulkDuplicateAction.ts	100.00% <ø> (ø)
src/hooks/useBulkDuplicateReportAction.ts	100.00% <ø> (ø)
src/hooks/useExpenseActions.ts	0.00% <ø> (ø)
src/hooks/useResetIOUType.ts	96.77% <100.00%> (ø)
...bs/Navigation/helpers/cleanupAfterExpenseCreate.ts	100.00% <100.00%> (ø)
...avigation/helpers/cleanupAfterSkipConfirmSubmit.ts	100.00% <100.00%> (ø)
...on/helpers/cleanupAndNavigateAfterExpenseCreate.ts	100.00% <100.00%> (ø)
src/libs/TransactionUtils/index.ts	87.51% <100.00%> (+0.02%)	⬆️
src/libs/actions/IOU/Duplicate.ts	91.64% <ø> (ø)
... and 22 more
... and 16 files with indirect coverage changes

[TaduJR]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

ℹ️ 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".

[TaduJR]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Delightful!

ℹ️ 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".

[TaduJR]

Notified @Valforte on Slack DM

[TaduJR]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. More of your lovely PRs please.

ℹ️ 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".

[github-actions]

🚧 @Valforte has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #88055.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-984230b36af-e140494-350b7ccd0a4cb356810b11b0ded2ce7bcee150a9/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-984230b-e140494-424740ab3f0aa26bdebc9cca3e216e1af793f4e2/index.html

Web 🕸️
https://88055.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/Valforte in version: 9.3.91-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS

[MelvinBot]

Help site review — no docs changes required

I reviewed the changes in this PR against the help site articles under docs/articles. No help site updates are needed, so I did not create a draft PR.

Why: This is a behavior-preserving internal refactor. It relocates post-creation navigation and cleanup out of the IOU action layer (requestMoney / trackExpense) into the view layer, per #84631. The user-facing flows the help site documents — creating, scanning, tracking, splitting, and moving expenses, plus where you land afterward — are intentionally unchanged. The PR's own test plan confirms this: every check verifies navigation "behaves identically" before and after.

Evidence

• All 54 changed files are src/ code or tests/ — no files under docs/articles and no src/languages/* copy changes (a reliable signal there is no new or changed user-facing text).
• No new features, buttons, tabs, or settings labels are introduced. The work is architectural: actions become pure write/Onyx primitives, and navigation moves into dedicated view-layer helpers (cleanupAfterExpenseCreate, cleanupAndNavigateAfterExpenseCreate, cleanupAfterSkipConfirmSubmit).
• Help articles describe what users do and where they end up, not the internal action-vs-view-layer split or post-create navigation timing this PR changes.

If reviewers determine any of these flows should land somewhere different than before (a real behavior change rather than a refactor), reply with @MelvinBot and the specifics and I'll draft the corresponding docs update.

---

@TaduJR, no linked help site PR was created because this refactor doesn't change any user-facing behavior documented on the help site. If you believe a flow's behavior actually changes for users, let me know what changes and I'll create the docs PR.

[OSBotify]

🚀 Deployed to staging by https://github.com/Valforte in version: 9.3.94-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS

[MelvinBot]

Help site review — no changes required

I reviewed the changes in this PR against the help site articles under App/docs/articles, and no help site updates are required.

Why: This is a pure internal architectural refactor. It moves post-create navigation and cleanup out of the IOU action layer (requestMoney / trackExpense) into view-layer helpers, removing the shouldHandleNavigation boolean. By design, the user-facing behavior is unchanged — the test plan explicitly verifies the same expense-creation, navigation, and highlight outcomes with no regressions.

What I checked

• All 56 changed files are source code (src/…), tests (tests/…), and one ESLint config (config/eslint/eslint.seatbelt.tsv). None touch App/docs/articles.
• No language/copy changes: no files under src/languages/* were modified. The translate references in the diff are the existing translation function being threaded through the relocated helpers; iou.fieldPending is a pre-existing key, not a new string.
• No new features, settings, tabs, buttons, or user-visible flows were introduced. Help site articles document user-facing product behavior (features, workspace settings, billing, integrations), none of which is altered by this refactor.

Since there's no user-facing behavior change, there's nothing to add or correct on the help site, so I have not opened a docs PR.

---

@TaduJR, I did not find any help site changes warranted by this refactor, so no draft docs PR was created. If you believe a specific article should still be updated as a result of these changes, let me know which behavior changed and I'll draft it.

[OSBotify]

🚀 Deployed to production by https://github.com/luacmartins in version: 9.3.94-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅