Expense - Expense is created in another report with error when Submissions are disabled

[thelullabyy]

Explanation of Change

Fixed Issues

$ #94282
PROPOSAL: N/A

Tests

Precondition:

• Disable Submissions in Workflows.
• Enable newManualExpenseFlow beta

1. Go to staging.new.expensify.com
2. Open self DM.
3. Send a message.
4. Open FAB > Create expense > Manual.
5. Enter amount.
6. Click Create expense.
7. Verify that we can create expense successfully

• Verify that no errors appear in the JS console

Offline tests

QA Steps

Precondition:

• Disable Submissions in Workflows.
• Enable newManualExpenseFlow beta

1. Go to staging.new.expensify.com
2. Open self DM.
3. Send a message.
4. Open FAB > Create expense > Manual.
5. Enter amount.
6. Click Create expense.
7. Verify that we can create expense successfully

• 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
• 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 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 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)
• 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)
• 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.
• 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

Screen.Recording.2026-06-24.at.01.29.33.mov

Android: mWeb Chrome

Screen.Recording.2026-06-24.at.01.30.45.mov

iOS: Native

Screen.Recording.2026-06-24.at.01.34.15.mov

iOS: mWeb Safari

Screen.Recording.2026-06-24.at.01.35.11.mov

MacOS: Chrome / Safari

Screen.Recording.2026-06-23.at.23.03.13.mov

[thelullabyy]

@codex review

[thelullabyy]

Old flow: the amount step (AmountSubmission) resolves the destination before navigating, and when the target is the self-DM it navigates to the confirmation with iouType: TRACK baked into the route. So the confirmation reads TRACK reliably → trackExpense.

New flow: the confirmation is embedded, and the conversion to TRACK happens after mount via an async navigation.setParams({iouType: TRACK}). createTransaction decides trackExpense vs requestMoney purely from that route iouType. When the conversion hasn't landed at submit time, it falls through to requestMoney with the current user as recipient → backend rejects with "you cannot request money from yourself."

[thelullabyy]

We should derive the track decision from the resolved participant (the same signal the old flow uses: destination is the self-DM), not the async route iouType

[chatgpt-codex-connector]

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

Reviewed commit: 3a047ce32f

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

[MelvinBot]

Checked the draft — the approach looks correct, and you're right that my earlier proposal was aimed at the wrong layer. 👍

Why my proposal missed it: I theorized the expense was being routed to a policy expense chat because of a stale autoReporting flag, and proposed gating shouldAutoReport in useDefaultParticipants.ts. But the real failure is simpler and one layer down: the sole recipient resolves to the current user, yet the route iouType was never converted to TRACK, so submission fell through to requestMoney — which the backend rejects ("you cannot request money from yourself"). My fix wouldn't have helped, because the confirmation step's iouType → TRACK conversion at IOURequestStepConfirmation.tsx:329-347 keys off isSelfDM only, and the failing participant carries the current user's accountID without that flag set.

Your fix addresses exactly that gap. Deciding isSelfDMDestination at the submission point (useExpenseSubmission.ts:241-248) catches both representations (isSelfDM === true or accountID === currentUserAccountID), and the guards (!isPolicyExpenseChat, !isSender, sole participant, excluding SPLIT/INVOICE/PAY) keep it from misfiring on real requests/splits/workspace submissions. Forcing trackReport = undefined so getTrackExpenseInformation defaults to the self-DM, and threading the self-DM into post-batch cleanup, are both consistent with the existing track path (optimisticChatReportID already pointed at optimisticSelfDMReportID). Nice to see the regression unit test covering it too.

CI is green (the two checklist failures are just the unchecked PR checklists), and Codex found no major issues.

A couple of optional, non-blocking thoughts:

1. Single source of truth. You now have two places that decide "this is really a self-DM track": the confirmation step's isSelfDM-based iouType conversion, and this new isSelfDMDestination. Longer term it might be worth having the confirmation step also recognize the accountID === currentUser case so iouType becomes TRACK and the rest of the code (which already branches on isTrackExpense) just works — rather than threading a parallel flag through the request/distance/track branches. Your localized approach is a perfectly reasonable deploy-blocker fix though; just flagging it for the reviewer's consideration.

2. accountID heuristic. Worth a sentence in the PR/code comment on why accountID === currentUserAccountID is a safe self-DM signal here (it's guarded against policy-expense-chat and sender participants), so a future reader doesn't worry it could capture a legitimate "expense involving me" case.

Thanks for digging into this and correcting the direction.

[MelvinBot]

I reviewed this — the approach is sound and at the right layer, and you correctly identified that my earlier proposal was aimed at the wrong place. Quick reconciliation for the record:

• My proposal changed shouldAutoReport in useDefaultParticipants, on the assumption that the expense was being routed to a policy expense chat. That's not what happens in the repro.
• The real mechanism (which your regression test pins down): the sole selected participant resolves to the current user themselves (accountID === currentUserAccountID) without the isSelfDM flag set. The confirmation step only converts iouType → TRACK when participant.isSelfDM === true, so iouType stays non‑TRACK, and the submit decision — which keys solely on isTrackExpense (iouType === TRACK) — falls through to requestMoney with yourself as the recipient. Fixing participant resolution upstream can't catch this because the participant is already "self."

Your fix encodes the correct invariant directly at the submission boundary: an expense whose only recipient is the current user can never be a money request, so it must be a track expense. Catching it in useExpenseSubmission.ts (isSelfDMDestination) is robust regardless of how the participant got there, and the !isPolicyExpenseChat / !isSender / non‑SPLIT/INVOICE/PAY guards correctly avoid hijacking legitimate submit‑to‑workspace and invoice flows. 👍

A few things worth tightening before it goes up for review:

1. Add negative-path test coverage for the guards. The one new test covers the happy path. Please also assert that a policy‑expense‑chat sole participant (owned by the current user) still routes through requestMoney, so a future refactor can't silently widen isSelfDMDestination and break submit‑to‑own‑workspace.

2. Verify the distance self‑DM path. You now skip createDistanceRequest for isSelfDMDestination (:794) and route it through trackExpenseIOUActions instead. That's the right outcome (a self distance expense should be tracked), but it's a newly exercised branch — please manually confirm a manual distance expense created from the FAB to the self DM works end‑to‑end, and ideally add a unit case for it.

3. Confirm equivalence for the existing (beta‑off) self‑DM track flow. Forcing trackReport = undefined also applies when isTrackExpense was already true and report was already the self‑DM. It should be a no‑op since getTrackExpenseInformation defaults to the self‑DM via optimisticChatReportID, but worth a quick check that the optimistic chat report ID resolves identically in that case.

Net: I agree with this direction over my earlier useDefaultParticipants proposal. Once the above are covered (and the new unit test passes in CI), this looks good to me.

[melvin-bot]

@situchan 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: 03a31d01ac

ℹ️ 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]

Update destination report when routing to self-DM

When the only recipient is the current user but the route iouType is still CREATE/REQUEST from another report, this branch now writes the expense through trackExpense to the self-DM, while IOURequestStepConfirmation still derives destinationReportID from the route report?.reportID unless iouType is already TRACK. On narrow/RHP dismiss-first paths the orchestrator reveals that stale destination and calls createTransaction(..., false), so the post-create cleanup navigation is skipped after this line and the user is left in the original report even though the expense was created in the self-DM. Please make the destination report calculation use the same self-DM condition before enabling this branch.

Useful? React with 👍 / 👎.