Android - Expense - Email not found error is shown after submitting expense to new user

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.75-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97874
Email or phone of affected tester (no customers): jsdoijnodsdisojo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Workspace Settings

Action Performed:

1. Launch Expensify app.
2. Create a new account.
3. Open FAB > Create expense > Manual.
4. Enter email of non-existing user.
5. Enter amount and tap Create expense.

Expected Result:

Expense will be created without error.

Actual Result:

Email not found error is shown after submitting expense to new user.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7255420_1788984166030.Screen_Recording_20260910_034627_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7255420

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/e6e3c4a66e5f1808eef59d28beb9436d4536fadc9eff3a1a39637c0a61d201ae

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #97874

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

@mountiny @marufsharifi you have been assigned to this deploy blocker because you reviewed the offending PR: #97874

[melvin-bot]

@JakubKorytko you have been assigned to this deploy blocker because you authored the offending PR: #97874

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Unconfirmed — App-side exposure is confirmed, but the "Email not found" string is returned by the API, so where the fix lands is not yet proven
Causing PR: #100215 - "feat: remove isNewManualExpenseFlowEnabled beta flag" by @thelullabyy (Medium confidence)
Related Issues: none found — no other issue or PR in this repo mentions an "Email not found" error

Recommendation: NEEDS INVESTIGATION

#97874 was auto-assigned only because its URL was pasted into the report's "caught during regression testing" field, and verification below shows it does not plausibly cause this; the flow the repro actually exercises was switched on for everyone by #100215, which is the best explanation for staging-yes/production-no. The exact failing API call still needs to be captured before we can say whether the fix is App-side or backend-side.

Assigned: @thelullabyy (PR author), @ikevin127 and @puneetlath (approving reviewers) from the highest-confidence causing PR (#100215). Existing assignees left in place.
Labels: No changes. DeployBlockerCash stays (the issue does not reproduce on production, and it is the only blocker label on the issue). DeployBlocker was never applied, so there is nothing to remove.

📋 Detailed Analysis

Evidence

1. #97874 is almost certainly not the cause.
The report's "If this was caught during regression testing, add the test name, ID and link" field contains https://github.com/Expensify/App/pull/97874. That is the QA link for the test the tester was running, not a diagnosis — and it is what Melvin keyed the auto-assignment off. On the merits, #97874 is a navigation pre-mount performance change. It does touch IOURequestStepConfirmation.tsx and useExpenseSubmission.ts, but it explicitly handles the brand-new-recipient case rather than breaking it: getReusableP2PReportID marks a recipient with no existing chat as an optimistic destination, and that flag is threaded through to the report route as isPendingCreation=true, which ReportFetchHandler uses to skip openReport for a client-generated reportID. It changes no participant field and no API payload.

2. The repro describes the new manual expense flow, which #100215 turned on for everyone.
The steps enter the recipient before the amount on a single confirmation screen. That is the new manual expense flow (participant picker owned by the confirmation page), not the legacy amount → participants → confirmation flow. #100215 deleted CONST.BETAS.NEW_MANUAL_EXPENSE_FLOW and every isNewManualExpenseFlowEnabled guard, including the one that previously wrapped <ParticipantPicker> inside IOURequestStepConfirmation and the one in MoneyRequestConfirmationList that used to navigate to the standalone participants step instead of opening the parent-owned picker.

3. This explains staging-only reproduction precisely.
Step 2 of the repro is "Create a new account." A brand-new account has no betas, so on production it still gets the legacy participants-step flow, which works. On staging the gate is gone, so the same brand-new account gets the new flow. That matches "Reproducible in staging: Yes / Reproducible in production: No" better than any other PR in this checklist.

4. Candidates considered and ruled out.

• Trim search term before deriving the phone/email search value in useSearchSelector #100031 (trim search term in useSearchSelector) — touches the invite-option derivation, but it adds the invite option for whitespace-padded logins. It is a no-op for a cleanly typed email and cannot remove a participant.
• Fix: open Confirm Details when pressing Enter in empty focused search on Workspace Members invite #98564 (Enter key on invite pickers) — only changes which control handles Enter, and when the search box is non-empty the focused row still handles it, i.e. unchanged for this repro. It does not alter the participant object.
• Part 7: Remove Onyx.connect() for the key: ONYXKEYS.PERSONAL_DETAILS_LIST in src/libs/actions/Report.ts #99836 (remove Onyx.connect() for PERSONAL_DETAILS_LIST) — plausible on the surface since it reworks optimistic personal details, but every touched site keeps an allPersonalDetails fallback, so no participant login is dropped.
• refactor: the new-transaction highlight rail and the wide RHP width model #98744 — touches MoneyRequestBuilder.ts / useExpenseSubmission.ts, but only for the new-transaction highlight rail and RHP width.

Verification

• Affected area: src/pages/iou/request/step/IOURequestStepConfirmation.tsx, src/components/MoneyRequestConfirmationList.tsx, src/pages/iou/request/ParticipantSearchResults.tsx, src/libs/actions/IOU/MoneyRequestBuilder.ts.
• feat: remove isNewManualExpenseFlowEnabled beta flag #100215 modifies the affected files: confirmed via gh pr view 100215 --json files — it edits MoneyRequestConfirmationList.tsx, IOURequestStepConfirmation.tsx, useDefaultParticipants.ts, DynamicIOURequestStepParticipants.tsx, IOURequestStartPage.tsx and ReportUtils.ts, and the recipient row in MoneyRequestConfirmationList now unconditionally calls onOpenParticipantPicker().
• Both PRs shipped in this build: gh api repos/Expensify/App/compare/9.4.74-2-staging...9.4.75-0-staging lists both #100215 and #97874.
• Timing: feat: remove isNewManualExpenseFlowEnabled beta flag #100215 merged 2026-09-09T16:33:46Z; the bug was filed 2026-09-09T22:24:59Z against 9.4.75-0.
• The error copy is not ours. Email not found (and any close variant) does not exist anywhere in src/languages/. The nearest strings are memberNotFound (Member not found.), which is not what the video shows. So the App is rendering an API error message verbatim, which is why the App diff alone cannot pin the root cause.

Root Cause

Confirmed so far: the recipient is now chosen through the confirmation page's own ParticipantPicker rather than the standalone participants step. For an email with no Expensify account, getUserToInviteOption synthesizes an option with a generated optimistic accountID and isOptimisticAccount: true; ParticipantSearchResults.sanitizedSelectedParticipant copies only a fixed field list onto the participant, and handleParticipantsAdded then generates a fresh optimistic reportID for the brand-new P2P recipient and writes it to the draft transaction. At submit, MoneyRequestBuilder derives the payer from participant.login.

Not yet confirmed: which of those hand-offs produces a payload the API rejects with "Email not found" — or whether the App payload is well-formed and the API is at fault. Nothing in the App diffs proves either way.

Concrete next steps to close this out:

1. Reproduce on staging with network logging and capture the failing command, its parameters (especially the participant's login/accountID) and the requestID from the response. That single data point decides App vs. backend and, if App, which hand-off drops the login.
2. If the deploy must be unblocked before that: feat: remove isNewManualExpenseFlowEnabled beta flag #100215 is a mechanical beta-flag removal, so restoring the gate is a clean, low-risk revert that returns brand-new accounts to the legacy participants-step flow. Prefer that over reverting [Performance] Pre-mount new expense destinations behind confirmation RHP #97874, which is unrelated to the recipient payload.