[Due for payment 2026-06-09] [$250] Expense - App crashes when deleting alias text after “+” in pasted email

[lanitochka17]

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.3.73
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-28526/folder/13177029/41237789/1410971112
Email or phone of affected tester (no customers): Applausetester+e@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

1.Login expensifail account
2.Tap fab - create expense - enter amount - next
3.From clipboard - add a email with plus
4. Delete the text next to plus and keep cursor at end

Expected Result:

The app should handle partial email edits gracefully without crashing and should allow the user to continue editing the email field normally.

Actual Result:

App crashes after pasting an email from clipboard (example: dreamnitethedragon+vegst@gmail.com), deleting the alias text +vegst, and keeping the cursor at the end of the email field.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7152866_1778674619744.Screenrecorder-2026-05-13-17-07-22-940.mp4

Bug7152866_1778674619734!Crash.txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054596139720191379
• Upwork Job ID: 2054596139720191379
• Last Price Increase: 2026-05-13
• Automatic offers:
• rohit9625 | Contributor | 111435079

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The crash occurs due to rapid FlashList item key instability combined with potential Hermes regex performance issues during text editing in the participant search field.

When the user edits the email in the search input, each debounced keystroke triggers getUserToInviteOption which calls generateAccountID(searchValue) — a hash of the current search string. Since the hash changes with every character typed/deleted, the keyForList for the "invite user" FlashList item changes on every keystroke, causing rapid native view unmount/mount cycles on Android Fabric.

The app already has two patches for similar Fabric mutation-ordering crashes (018+fix-dropping-mutations-in-transactions, 019+fix-crash-when-deleting-expense), but the rapid key changes from generateAccountID may trigger an uncovered edge case.

Additionally, per keystroke the search flow runs the complex EMAIL_BASE_REGEX (from expensify-common) 2–3 times via Str.isValidEmail in getUserToInviteOption and getHeaderMessage, plus ~6 parsePhoneNumber calls through getSearchValueForPhoneOrEmail and appendCountryCode. This heavy per-keystroke computation on Hermes could block the JS thread long enough to contribute to the crash via ANR on Android.

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

Stabilize the FlashList key for the userToInvite option so it doesn't change on every keystroke. Instead of using generateAccountID(searchValue) (which produces a different hash per search string) as the key, use a stable sentinel key like "user-to-invite" for the keyForList property of the invite option. The optimisticAccountID can still use the hash internally for Onyx purposes, but the list item key should remain constant to prevent rapid native view recycling.

In getUserToInviteOption, after creating the option, override keyForList with a stable value so FlashList treats it as the same item being updated rather than a new item each time.

What alternative solutions did you explore? (Optional)

1. Debounce the email validation more aggressively — would reduce frequency but not eliminate the key instability issue.
2. Add another React Native Fabric patch — addresses the symptom (native crash) rather than the root cause (unstable keys causing unnecessary mount/unmount cycles).
3. Cache the regex result — would help performance but doesn't fix the key instability which is the primary crash vector.

Supporting evidence

Data flow per keystroke:

1. User edits email → onChangeText → debounced state update
2. getSearchValueForPhoneOrEmail runs parsePhoneNumber(appendCountryCode(...)) — 2 parsePhoneNumber calls
3. getValidOptions → getUserToInviteOption — 2 more parsePhoneNumber calls + 1-2 Str.isValidEmail calls with complex regex
4. getHeaderMessage — 1 more parsePhoneNumber + 1 more Str.isValidEmail
5. generateAccountID(searchValue) produces new hash → new keyForList → FlashList unmounts old item, mounts new one
6. On Android Fabric, rapid mount/unmount can trigger mutation transaction ordering issues → native crash

Existing patches confirm the pattern: The two React Native patches (018 and 019) fix crashes caused by merged Fabric mounting transactions where DELETE+CREATE of the same view tag race. The unstable keyForList from generateAccountID creates exactly this scenario.

Android-only: iOS uses JSC (not Hermes for regex) and has different Fabric transaction batching, explaining why the crash is Android-specific.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-13 16:15:43 UTC.

Proposal

What is the root cause of that problem?

The crash happens on the "Who's this for?" step of the money-request flow, which mounts a participant search input. On every keystroke that input runs the search term through a phone-number-aware normalizer before matching it against contacts. The exact chain Expensify uses on this screen is documented in issue #32242 and looks like:

const parsedPhoneNumber = parsePhoneNumber(
    LoginUtils.appendCountryCode(Str.removeSMSDomain(searchInputValue)),
);

The chain calls parsePhoneNumber from libphonenumber-js — which is an alias for parsePhoneNumberWithError and, per the library's README, throws a ParseError on inputs it can't parse, rather than returning undefined the way parsePhoneNumberFromString does.

In the reporter's repro, the intermediate string after deleting the alias is dreamnitethedragon+@gmail.com. That string is structurally an email but contains a +, which is the very token libphonenumber-js treats as the start of an international dialing prefix. With the rest of the string being non-digit, parsePhoneNumber throws ParseError: NOT_A_NUMBER (or TOO_SHORT, depending on what appendCountryCode produces). Because this throw happens synchronously inside the input's change handler, two things compound:

1. The React render cycle for that frame fails, so the input never settles into the new value cleanly.
2. On Android specifically, the participant input is a MarkdownTextInput whose native side computes highlight ranges synchronously alongside the JS onChange. A JS throw mid-edit leaves the native side with a stale range pointer for the next text update — and the next text update is exactly what happens when the user keeps the cursor at the end and the input re-evaluates. That second update hits an invalid range, and the native code aborts the process.

This explains why the crash is Android-only (iOS uses the React error boundary path) and why "delete alias text and keep the cursor at the end" is the specific trigger — that's the keystroke sequence that produces the throwing-then-re-rendering shape.

What I've verified vs what's a hypothesis:

• ✅ Verified: parsePhoneNumber from libphonenumber-js throws on non-numeric input (README).
• ✅ Verified: Expensify's search flow uses parsePhoneNumber(LoginUtils.appendCountryCode(Str.removeSMSDomain(value))) (#32242 thread).
• ⚠️ Hypothesis (needs confirmation with logcat): the specific throw site is the participant search on the money-request flow, not a different consumer of the same chain. A debug-build repro with console.error boundaries on the input's onChange would confirm.

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

I think we should make the phone-parse defensive at the central call site so any partially-typed string is safe, and add a unit-test guard on the exact intermediate strings the user types through.

1. Switch from parsePhoneNumber to parsePhoneNumberFromString in the search-normalization helper. parsePhoneNumberFromString returns PhoneNumber | undefined instead of throwing, which is the contract we actually want when the input is a half-typed token. Wherever the search chain currently sits (likely in src/libs/OptionsListUtils or a shared helper used by MoneyRequestParticipantsSelector), the call should become:

- import {parsePhoneNumber} from '@libs/PhoneNumber';
+ import {parsePhoneNumberFromString} from 'libphonenumber-js';
  // ...
- const parsedPhoneNumber = parsePhoneNumber(
-     LoginUtils.appendCountryCode(Str.removeSMSDomain(searchInputValue)),
- );
- const searchValue = parsedPhoneNumber.possible
-     ? parsedPhoneNumber.number.e164
-     : searchInputValue.toLowerCase();
+ const parsedPhoneNumber = parsePhoneNumberFromString(
+     LoginUtils.appendCountryCode(Str.removeSMSDomain(searchInputValue)),
+ );
+ const searchValue = parsedPhoneNumber?.isPossible()
+     ? parsedPhoneNumber.number
+     : searchInputValue.toLowerCase();

The exact import path may already be wrapped by Expensify's @libs/PhoneNumber; if so, the equivalent fix is to make that wrapper's parsePhoneNumber return undefined-on-error instead of throwing, with a single try/catch inside the wrapper.

2. Don't route email-shaped strings into the phone parser at all. The + in name+alias@domain is a Gmail-style alias, not a country code. A cheap predicate before the parse keeps phone-only inputs going through libphonenumber-js and leaves emails alone:

+ // A '+' inside an email's local part is a Gmail alias, not a country
+ // code. Only route to phone parsing when '@' is absent.
+ if (searchInputValue.includes('@')) {
+     return {value: searchInputValue.toLowerCase(), isPhone: false};
+ }
  const parsedPhoneNumber = parsePhoneNumberFromString(/* ... */);

This is belt-and-braces with (1): even if a future change re-introduces a throwing parser, emails never reach it.

3. Add a regression test that walks the exact keystroke sequence. The bug is shaped by the intermediate string, not the final one. A test in tests/unit/LoginUtilsTest.ts (or wherever the search helper is tested) should assert no throw across the edit path:

it('does not throw while editing a Gmail-alias email', () => {
    const states = [
        'dreamnitethedragon+vegst@gmail.com',  // pasted
        'dreamnitethedragon+vegs@gmail.com',
        'dreamnitethedragon+veg@gmail.com',
        'dreamnitethedragon+ve@gmail.com',
        'dreamnitethedragon+v@gmail.com',
        'dreamnitethedragon+@gmail.com',       // empty alias — the trigger
    ];
    states.forEach((s) => expect(() => normalizeSearchInput(s)).not.toThrow());
});

These six strings are exactly what the input transitions through; if any of them throws, the bug comes back.

4. (Confirm-before-shipping) Capture an Android logcat during repro. Before merging, it's worth grabbing a adb logcat from a debug build on the Redmi Note 10s the reporter used. If the trace lands inside react-native-live-markdown's native module, we have a separate library-level bug to file upstream — the JS fix is still correct, but we'd want the native code to also stop crashing on a thrown change handler. If the trace is purely JS, the fix above is sufficient on its own.

What alternative solutions did you explore?

• Wrap the input's onChange in a try/catch and swallow errors. Fixes the visible crash but masks the bug everywhere else the same chain is called (new chat, group chat, search). Centralizing the fix in the parser is one place to maintain instead of every consumer.
• Strip + from the input before parsing. Breaks Gmail-alias support for legitimate inputs like user+sales@gmail.com vs user+billing@gmail.com (they'd collapse to the same login). The + is meaningful in emails; the parser just shouldn't read it as a phone hint when @ is present.
• Use extract: false on parsePhoneNumberFromString. Stricter and would correctly reject name+@domain as not-a-phone, but it also changes behavior for legitimate phone inputs with surrounding whitespace or punctuation, which is a larger blast radius than this bug needs.
• Wait for a logcat capture before fixing anything. Tempting because the crash log is uninformative, but the hypothesis is well-supported and the fix is defensive — switching from a throwing API to a returning API is strictly safer regardless of whether the specific crash trace lands exactly where I'm describing. Worth shipping, then confirming.

[KJ21-ENG]

Proposal

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

On Android native, the expense participant picker can crash while the user edits a pasted plus-addressed email in the "Name, email, or phone number" field. The user should be able to move through intermediate email states while editing without the participant list crashing.

What is the root cause of that problem?

ParticipantSearchResults wires the participant picker search input directly into useSearchSelector, then renders any availableOptions.userToInvite result as a one-row section in SelectionListWithSections.

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

Lines 225 to 244 in 053707d

	const {searchTerm, debouncedSearchTerm, setSearchTerm, availableOptions, selectedOptions, toggleSelection, areOptionsInitialized, onListEndReached, contactState} = useSearchSelector({
	selectionMode: isIOUSplit ? CONST.SEARCH_SELECTOR.SELECTION_MODE_MULTI : CONST.SEARCH_SELECTOR.SELECTION_MODE_SINGLE,
	searchContext: CONST.SEARCH_SELECTOR.SEARCH_CONTEXT_GENERAL,
	includeUserToInvite: !isCategorizeOrShareAction && !isPerDiemRequest && !isTimeRequest,
	excludeLogins: CONST.EXPENSIFY_EMAILS_OBJECT,
	includeRecentReports: true,
	maxRecentReportsToShow: CONST.IOU.MAX_RECENT_REPORTS_TO_SHOW,
	getValidOptionsConfig,
	shouldInitialize: didScreenTransitionEnd,
	enablePhoneContacts: isNative,
	contactOptions: contacts,
	initialSelected: participants as OptionData[],
	onSelectionChange: handleSelectionChange,
	onSingleSelect: (option: OptionData) => {
	if (isIOUSplit) {
	return;
	}
	addSingleParticipant(option);
	},
	});

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

Lines 330 to 356 in 053707d

	if (
	!isWorkspacesOnly &&
	availableOptions.userToInvite &&
	!isCurrentUser(
	{
	...availableOptions.userToInvite,
	accountID: availableOptions.userToInvite?.accountID ?? CONST.DEFAULT_NUMBER_ID,
	status: availableOptions.userToInvite?.status ?? undefined,
	},
	loginList,
	currentUserEmail,
	) &&
	!isPerDiemRequest &&
	!isTimeRequest
	) {
	sections.push({
	title: undefined,
	data: [availableOptions.userToInvite].map((participant) => {
	const isPolicyExpenseChat = participant?.isPolicyExpenseChat ?? false;
	const privateIsArchived = privateIsArchivedMap[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${userToInviteExpenseReport?.reportID}`];
	return isPolicyExpenseChat
	? getPolicyExpenseReportOption(participant, privateIsArchived, personalDetails, userToInviteExpenseReport, userToInviteExpenseReportPolicy, reportAttributesDerived)
	: getParticipantsOption(participant, personalDetails);
	}),
	sectionIndex: 5,
	});

That row is created for valid email-like search values by getUserToInviteOption. A plus-addressed email and the intermediate +@domain value still pass the email branch, so deleting the alias text can keep toggling the list between empty/searching and an invite-only row.

App/src/libs/OptionsListUtils/index.ts

Lines 1947 to 1965 in 053707d

	const parsedPhoneNumber = parsePhoneNumber(appendCountryCode(Str.removeSMSDomain(searchValue), countryCode));
	const isCurrentUserLogin = isCurrentUser({login: searchValue} as PersonalDetails, loginList, currentUserEmail);
	const isInSelectedOption = selectedOptions.some((option) => 'login' in option && option.login === searchValue);
	const isValidEmail = Str.isValidEmail(searchValue) && !Str.isDomainEmail(searchValue) && !Str.endsWith(searchValue, CONST.SMS.DOMAIN);
	const isValidPhoneNumber = parsedPhoneNumber.possible && Str.isValidE164Phone(getPhoneNumberWithoutSpecialChars(parsedPhoneNumber.number?.input ?? ''));
	const isInOptionToExclude = loginsToExclude[addSMSDomainIfPhoneNumber(searchValue).toLowerCase()];
	const trimmedSearchInputValue = searchInputValue?.trim();
	const shouldUseSearchInputValue = shouldAcceptName && !!trimmedSearchInputValue && !isValidEmail && !isValidPhoneNumber;
	const displayValue = shouldUseSearchInputValue ? trimmedSearchInputValue : searchValue;
	// Angle brackets are not valid characters for user names
	const hasInvalidCharacters = shouldAcceptName && (searchValue.includes('<') || searchValue.includes('>'));
	if (isCurrentUserLogin || isInSelectedOption || (!isValidEmail && !isValidPhoneNumber && !shouldAcceptName) || isInOptionToExclude || hasInvalidCharacters) {
	return null;
	}
	// Generates an optimistic account ID for new users not yet saved in Onyx
	const optimisticAccountID = generateAccountID(searchValue);

SelectionListWithSections flattens those sections with initialFocusedIndex initialized to -1 when no initiallyFocusedItemKey matches. The expense participant picker does not pass an initially focused key, so the flattened data can contain rows while initialFocusedIndex remains -1.

App/src/components/SelectionList/hooks/useFlattenedSections.ts

Lines 43 to 49 in 053707d

	function useFlattenedSections<TItem extends ListItem>(sections: Array<Section<TItem>>, initiallyFocusedItemKey?: string | null): UseFlattenedSectionsResult<TItem> {
	return useMemo(() => {
	const data: Array<FlattenedItem<TItem>> = [];
	const selectedOptions: TItem[] = [];
	const disabledIndices: number[] = [];
	let focusedIndex = -1;
	let firstNonHeaderIndex = -1;

App/src/components/SelectionList/hooks/useFlattenedSections.ts

Lines 97 to 104 in 053707d

	return {
	flattenedData: data,
	disabledIndexes: disabledIndices,
	itemsCount: itemsTotalCount,
	selectedItems: selectedOptions,
	initialFocusedIndex: focusedIndex,
	firstFocusableIndex: firstNonHeaderIndex === -1 ? 0 : firstNonHeaderIndex,
	};

The crash boundary is that BaseSelectionListWithSections passes initialScrollIndex={initialScrollIndex ?? initialFocusedIndex} straight to FlashList. When initialFocusedIndex is -1, the native list receives an invalid initial index during the search-result remount instead of receiving undefined or the first focusable row.

App/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx

Lines 412 to 423 in 053707d

	{itemsCount === 0 && (shouldShowLoadingPlaceholder || shouldShowListEmptyContent) ? (
	renderListEmptyContent()
	) : (
	<FlashList
	role={getListboxRole(canSelectMultiple)}
	data={flattenedData}
	renderItem={renderItem}
	ref={listRef}
	extraData={flattenedData.length}
	getItemType={getItemType}
	initialScrollIndex={initialScrollIndex ?? initialFocusedIndex}
	keyExtractor={(item) => ('flatListKey' in item ? item.flatListKey : item.keyForList)}

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

Clamp the initialScrollIndex passed to FlashList in BaseSelectionListWithSections so it is only supplied when the chosen index is within flattenedData bounds. Compute a local value such as resolvedInitialScrollIndex = initialScrollIndex ?? initialFocusedIndex, then pass undefined when it is < 0 or >= flattenedData.length.

This keeps the focus model unchanged: useSearchFocusSync can still move focus to the first focusable row after the search value changes, but the initial FlashList mount never receives -1 while the invite-only row is appearing/disappearing during partial email edits.

Scope boundaries:

• Files touched: src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx — FlashList initialScrollIndex prop in BaseSelectionListWithSections.
• Platforms: all platforms using SelectionListWithSections, with the reported crash path on Android native.
• Code paths / callers explicitly NOT touched: participant option generation, email validation, searchUserInServer, IOU creation/submission actions, and backend search APIs.
• API contracts or backend behavior changes: no.

What alternative solutions did you explore? (Optional)

I considered special-casing plus-addressed emails in ParticipantSearchResults or OptionsListUtils, but that would only hide this reproduction. The invalid list index can happen for any sectioned selection list that has rows without an initially focused item, so guarding the FlashList boundary fixes the crash without changing which emails are considered inviteable.

There are no existing strict human or bot proposals in the issue thread at draft time.

[melvin-bot]

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

[melvin-bot]

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

[mukhrr]

Proposal

What is the root cause of that problem?

The participant selector on the IOU "next" step runs every keystroke of the search field through getSearchValueForPhoneOrEmail, which unconditionally feeds the raw text into parsePhoneNumber (via appendCountryCode + Str.removeSMSDomain):

App/src/libs/OptionsListUtils/index.ts

Lines 1369 to 1372 in 9d65949

	function getSearchValueForPhoneOrEmail(searchTerm: string, countryCode: number) {
	const parsedPhoneNumber = parsePhoneNumber(appendCountryCode(Str.removeSMSDomain(searchTerm), countryCode));
	return parsedPhoneNumber.possible ? (parsedPhoneNumber.number?.e164 ?? '') : searchTerm.toLowerCase();
	}

When the user pastes dreamnitethedragon+vegst@gmail.com and then deletes the alias portion (+vegst), the input goes through transient states like dreamnitethedragon+@gmail.com, +@gmail.com, and + while the cursor is held at the end. Because the string starts with +, awesome-phonenumber treats it as an international phone candidate and returns possible: true. Our wrapper then runs:

App/src/libs/PhoneNumber.ts

Lines 12 to 34 in 9d65949

	function parsePhoneNumber(phoneNumber: string, options?: PhoneNumberParseOptions): ParsedPhoneNumber {
	const parsedPhoneNumber = originalParsePhoneNumber(phoneNumber, options);
	if (!parsedPhoneNumber.possible) {
	return parsedPhoneNumber;
	}
	const phoneNumberWithoutSpecialChars = phoneNumber.replaceAll(CONST.REGEX.SPECIAL_CHARS_WITHOUT_NEWLINE, '');
	if (!CONST.REGEX.PHONE_NUMBER.test(phoneNumberWithoutSpecialChars)) {
	return {
	...parsedPhoneNumber,
	valid: false,
	possible: false,
	number: {
	...parsedPhoneNumber.number,
	e164: phoneNumberWithoutSpecialChars,
	international: phoneNumberWithoutSpecialChars,
	national: phoneNumberWithoutSpecialChars,
	rfc3966: `tel:${phoneNumberWithoutSpecialChars}`,
	significant: phoneNumberWithoutSpecialChars,
	},
	} as ParsedPhoneNumberInvalid;
	}

phoneNumber.replaceAll(CONST.REGEX.SPECIAL_CHARS_WITHOUT_NEWLINE, '') strips everything except digits, leaving an empty (or near‑empty) phoneNumberWithoutSpecialChars. That empty value is then propagated back into the option list as e164, used to build sections / userToInvite, and on Android the downstream createOption → avatar/icon path hits the empty‑login branch and throws inside the list renderer, taking the screen down. The same path also feeds getUserToInviteOption, which calls generateAccountID('') and creates an option keyed by an empty login:

App/src/libs/OptionsListUtils/index.ts

Lines 1947 to 1972 in 9d65949

	const parsedPhoneNumber = parsePhoneNumber(appendCountryCode(Str.removeSMSDomain(searchValue), countryCode));
	const isCurrentUserLogin = isCurrentUser({login: searchValue} as PersonalDetails, loginList, currentUserEmail);
	const isInSelectedOption = selectedOptions.some((option) => 'login' in option && option.login === searchValue);
	const isValidEmail = Str.isValidEmail(searchValue) && !Str.isDomainEmail(searchValue) && !Str.endsWith(searchValue, CONST.SMS.DOMAIN);
	const isValidPhoneNumber = parsedPhoneNumber.possible && Str.isValidE164Phone(getPhoneNumberWithoutSpecialChars(parsedPhoneNumber.number?.input ?? ''));
	const isInOptionToExclude = loginsToExclude[addSMSDomainIfPhoneNumber(searchValue).toLowerCase()];
	const trimmedSearchInputValue = searchInputValue?.trim();
	const shouldUseSearchInputValue = shouldAcceptName && !!trimmedSearchInputValue && !isValidEmail && !isValidPhoneNumber;
	const displayValue = shouldUseSearchInputValue ? trimmedSearchInputValue : searchValue;
	// Angle brackets are not valid characters for user names
	const hasInvalidCharacters = shouldAcceptName && (searchValue.includes('<') || searchValue.includes('>'));
	if (isCurrentUserLogin || isInSelectedOption || (!isValidEmail && !isValidPhoneNumber && !shouldAcceptName) || isInOptionToExclude || hasInvalidCharacters) {
	return null;
	}
	// Generates an optimistic account ID for new users not yet saved in Onyx
	const optimisticAccountID = generateAccountID(searchValue);
	const personalDetailsExtended = {
	...personalDetails,
	[optimisticAccountID]: {
	accountID: optimisticAccountID,
	login: searchValue,
	},
	};

The reason "keep cursor at end" matters is that it forces the debounced search term to update on each character removal, so every intermediate +… value is processed instead of just the final clean email.

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

Short‑circuit the phone parse when the input is clearly not a phone number (contains @, or is just the lone + sentinel). The cheapest place is getSearchValueForPhoneOrEmail, since every callsite goes through it:

 function getSearchValueForPhoneOrEmail(searchTerm: string, countryCode: number) {
-    const parsedPhoneNumber = parsePhoneNumber(appendCountryCode(Str.removeSMSDomain(searchTerm), countryCode));
-    return parsedPhoneNumber.possible ? (parsedPhoneNumber.number?.e164 ?? '') : searchTerm.toLowerCase();
+    // Skip phone parsing for inputs that can't be phone numbers (emails, or stray "+"
+    // produced while the user is mid-edit). awesome-phonenumber otherwise flags any
+    // string starting with "+" as `possible`, and our wrapper then collapses it to an
+    // empty e164 which crashes downstream option rendering on Android.
+    const trimmed = searchTerm.trim();
+    if (!trimmed || trimmed === '+' || trimmed.includes('@')) {
+        return searchTerm.toLowerCase();
+    }
+    const parsedPhoneNumber = parsePhoneNumber(appendCountryCode(Str.removeSMSDomain(trimmed), countryCode));
+    return parsedPhoneNumber.possible && parsedPhoneNumber.number?.e164 ? parsedPhoneNumber.number.e164 : searchTerm.toLowerCase();
 }

As a defense in depth, I'd also guard getUserToInviteOption against building an option with an empty login — if searchValue is falsy after trimming, return null early so the section never receives a malformed entry:

-    if (!searchValue) {
+    if (!searchValue?.trim()) {
         return null;
     }

No other call sites need to change — every consumer of getSearchValueForPhoneOrEmail (useSearchSelector.base.ts, ApproverSelectionList, WorkspaceMembersSelectionList, ShareBankAccount) already expects a lowercase fallback when the input isn't a phone, so the new branch is behavior‑preserving for non‑email inputs.

What alternative solutions did you explore? (Optional)

• Fixing it inside parsePhoneNumber itself (returning possible: false when the stripped result is empty). It works, but parsePhoneNumber is shared with login/signup flows where the empty‑digits behavior is already relied upon elsewhere, so I'd rather keep the guard at the call site that's specifically about search input.
• Debouncing harder so the bad intermediate states are never sent. That hides the crash on fast typists but doesn't fix it — slow editing (which is exactly what the repro does) still reproduces.

[aswin-s]

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

When a user pastes an email with a plus-addressed alias (e.g., dreamnitethedragon+vegst@gmail.com) into the participant picker during a money request flow, then deletes the alias portion and keeps the cursor at the end, the app crashes on Android. The expected behavior is that the app should handle partial email edits gracefully and allow the user to continue editing without crashing.

What is the root cause of that problem?

The crash originates in BaseSelectionListWithSections.tsx:412–423. When a user deletes the alias text, the search term becomes name+@domain.com, which matches the email pattern. The participant picker's getUserToInviteOption returns a row that mounts and unmounts with each keystroke because the row's keyForList value is derived from the unstable intermediate search string — meaning every character deletion produces a new key, causing FlashList to fully unmount and remount the row on each change.

ParticipantSearchResults does not supply initiallyFocusedItemKey to the base selection list, so initialFocusedIndex (initialized to -1 in useFlattenedSections.ts:48) remains -1 throughout the search. When FlashList remounts on the intermediate keystroke, it receives an out-of-bounds initialScrollIndex={-1}, which triggers a native crash on Android Fabric during the list's mounting transaction. Android Fabric's synchronous native mounting is stricter than the old paper renderer: it validates list props eagerly during the mounting commit, so an invalid initialScrollIndex causes an unrecoverable crash rather than a silent no-op.

The working analog is the scrollToIndex function in the same file, which guards against invalid indices before calling the native list API. The fix applies the same bounds-checking pattern.

App/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx

Lines 412 to 423 in c5403b4

	{itemsCount === 0 && (shouldShowLoadingPlaceholder || shouldShowListEmptyContent) ? (
	renderListEmptyContent()
	) : (
	<FlashList
	role={getListboxRole(canSelectMultiple)}
	data={flattenedData}
	renderItem={renderItem}
	ref={listRef}
	extraData={flattenedData.length}
	getItemType={getItemType}
	initialScrollIndex={initialScrollIndex ?? initialFocusedIndex}
	keyExtractor={(item) => ('flatListKey' in item ? item.flatListKey : item.keyForList)}

App/src/components/SelectionList/hooks/useFlattenedSections.ts

Line 48 in c5403b4

let focusedIndex = -1;

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

1. File: src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx
   Function: BaseSelectionListWithSections
   Edit: Replace the initialScrollIndex prop passed to FlashList (line 412–423) with a computed index that clamps the value to the valid range [0, flattenedData.length). When the resolved index falls outside bounds — including when flattenedData is empty or not yet populated during initial render — pass undefined instead. This prevents the invalid -1 from reaching the native list while preserving the focus behavior—useSearchFocusSync still moves focus once data settles. The exact change is to wrap the inline prop:

   initialScrollIndex={(() => {
       const resolved = initialScrollIndex ?? initialFocusedIndex;
       const length = flattenedData?.length ?? 0;
       return resolved >= 0 && length > 0 && resolved < length ? resolved : undefined;
   })()}

   The guard flattenedData?.length ?? 0 covers the case where flattenedData is not yet populated during the initial render, and length > 0 ensures we never pass an index into an empty list. This matches the bounds-check pattern already used by the scrollToIndex function in the same file, and it is safe on both the old Paper renderer and Android Fabric because passing undefined causes FlashList to skip the native scroll-to call entirely.

What alternative solutions did you explore? (Optional)

Stabilize keyForList of the userToInvite row to a sentinel like 'user-to-invite' instead — this would reduce the remounting churn in intermediate search states and address the instability at the option-generation layer. However, this approach does not remove the invalid initialScrollIndex={-1} prop itself. Any sectioned list caller that does not supply initiallyFocusedItemKey can still trigger the out-of-bounds index at the FlashList boundary on the initial render. The root cause is at the prop interface, not at the option-generation layer, so the fix belongs in BaseSelectionListWithSections. Stabilizing keyForList is a worthwhile follow-up that reduces unnecessary remounts across all callers, but it does not protect the native mounting path from receiving an invalid index.

[Hossiy21]

Proposal

What is the root cause of the problem?

The crash is caused by FlashList receiving an invalid initialScrollIndex during participant list re-rendering while the user edits a pasted plus-addressed email.

During the edit flow:

dreamnitethedragon+vegst@gmail.com
→ dreamnitethedragon+@gmail.com

the participant selector rapidly rebuilds sections inside SelectionListWithSections.

useFlattenedSections() initializes focusedIndex with -1 when there is no matching focused item:

let focusedIndex = -1;

That value is later passed directly into FlashList:

initialScrollIndex={initialScrollIndex ?? initialFocusedIndex}

inside:

src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx

When the invite-only row is mounted/remounted during partial email edits, Android native FlashList receives -1 as the initial index and crashes.

The +alias email itself is not the actual problem. It only creates the intermediate search states that expose the invalid list index path.

---

What changes should we make to solve the problem?

Guard the initialScrollIndex before passing it to FlashList.

Instead of directly forwarding:

initialScrollIndex ?? initialFocusedIndex

compute a safe resolved index first:

const resolvedInitialScrollIndex =
    initialScrollIndex ?? initialFocusedIndex;

const safeInitialScrollIndex =
    resolvedInitialScrollIndex >= 0 &&
    resolvedInitialScrollIndex < flattenedData.length
        ? resolvedInitialScrollIndex
        : undefined;

then pass:

initialScrollIndex={safeInitialScrollIndex}

This keeps the existing focus behavior unchanged while preventing invalid native list initialization during rapid participant-search updates.

---

Why this approach?

• Fixes the actual native crash boundary instead of special-casing email parsing.
• Covers other future cases where section rebuilding may temporarily produce -1.
• Minimal blast radius.
• No backend/API changes.
• No behavior changes to participant search, email validation, or phone parsing.

---

Regression test coverage

I would also add a regression test covering:

1. Pasting a plus-addressed email
2. Deleting alias characters after +
3. Re-rendering participant sections with no focused item
4. Verifying FlashList never receives a negative initialScrollIndex