[$250] Android - Crash - App crashes when user tries to add member to workspace

[jponikarchuk]

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.90-3
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/folder/13176702/test-cases/56174052
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Xiaomi RedMi Note 10 / Android 12
App Component: Other

Action Performed:

Precondition: account with workspace.

1. Go to worksapce > Members
2. Tap invite member
3. Enter member's email
4. Tap on email
5. Tap application back arrow

Expected Result:

4. Email selected
5. User navigated on previous page

Actual Result:

4. Email not selected
5. Application crashes

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Screenrecorder-2026-06-01-23-30-42-403.1.mp4

log.txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061551553635882016
• Upwork Job ID: 2061551553635882016
• Last Price Increase: 2026-06-08

[MelvinBot]

Proposal

What is the root cause of that problem?

Tapping the in-app back arrow on the workspace Invite member page while the soft keyboard is still open (it's open because the user just typed an email) starts a navigation transition while a keyboard inset animation is still in-flight. On Android this triggers a native crash:

InsetsController IllegalStateException: Can't change insets on an animation that is cancelled

This is the exact same crash class that was already fixed for the forward "Next" navigation in Expensify/App#88754 / PR Expensify/App#90625, which added Keyboard.dismiss() to inviteUser (DynamicWorkspaceInvitePage.tsx:173). However, the back-button handler (DynamicWorkspaceInvitePage.tsx:259-262) navigates via Navigation.goBack(dynamicBackPath) without first dismissing the keyboard — so the same race still crashes on the back path.

The "email not selected" observation is a benign side effect: tapping the row clears the search input and moves the selected email into a top "selected" section, so the row appears to vanish from where it was typed. The crash is the real defect.

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

Dismiss the keyboard before navigating back, mirroring the existing fix on the forward path. In the onBackButtonPress handler of DynamicWorkspaceInvitePage, call Keyboard.dismiss() before Navigation.goBack(dynamicBackPath). Keyboard is already imported in this file, so this is a one-line addition consistent with inviteUser.

What alternative solutions did you explore? (Optional)

A more robust option would be to dismiss the keyboard centrally on navigation transitions (e.g. in HeaderWithBackButton or the navigator) so every screen is covered rather than patching handlers individually. The minimal, consistent fix is the per-handler dismiss already used on the forward path.

Investigation details & evidence

• Crash signature is documented in PR Expensify/App#90625 (fix for Expensify/App#88754): "Android InsetsController crash (IllegalStateException: Can't change insets on an animation that is cancelled) caused by a race condition" when navigating while a keyboard animation is in-flight.
• Forward nav already dismisses the keyboard: DynamicWorkspaceInvitePage.tsx:173.
• Back handler does not: DynamicWorkspaceInvitePage.tsx:259-262.
• Same platform (Android App), same screen, same trigger (navigate while keyboard open) as the already-fixed Expensify/App#88754.
• This page is a recent migration to dynamic routes + useSearchSelector (introduced ~2026-05-21); the bug surfaced in v9.3.90-3.
• A JS-only trace of the dynamic-routes back path showed Navigation.goBack resolves to a valid route and is wrapped in a try/catch (TransitionTracker), so the crash is not in JS — it's the native keyboard/inset race, matching the documented InsetsController exception.
• Confidence: Medium. Strong circumstantial match to the documented crash and the already-patched sibling handler, but not verified against a Sentry stack for this specific issue (Sentry was not accessible during this investigation). To confirm: pull the Android crash stack for this issue and verify it is IllegalStateException: Can't change insets on an animation that is cancelled.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92280) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-01 20:56:19 UTC.

Proposal

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

On the workspace invite page, after typing an email, tapping the matching "Add 'email'" row, then immediately tapping the back arrow, the app crashes on Android. The reporter notes the row visually appears not selected before the back tap. This reproduces on staging and production on Xiaomi RedMi Note 10 / Android 12.

What is the root cause of that problem?

The crash is the same Android WindowInsetsAnimationController.IllegalStateException ("Can't change insets on an animation that is cancelled") that was previously fixed in inviteUser by PR #90625 — a race between an in-flight Android keyboard close animation and the screen transition triggered by Navigation.goBack(...). PR #90625 covered only the "Next" path; the same race still triggers on the back path with this exact repro.

Trace of the repro: the user opens the invite page, which auto-focuses the text input via useFocusEffect in src/components/SelectionList/components/TextInput.tsx#L115-L131 and opens the IME. They type an email, so availableOptions.userToInvite is populated and rendered in section 2. They tap that row, which routes through handleToggleSelection → toggleSelection (src/hooks/useSearchSelector/base.ts#L383-L422). Crucially, the underlying FlashList uses keyboardShouldPersistTaps="always" (BaseSelectionListWithSections.tsx), so tapping the row leaves the IME open. The selection state updates internally, but because the row immediately becomes hidden from section 2 by the guard availableOptions.userToInvite && !availableOptions.userToInvite.isSelected and re-renders as a small entry in the top selectedNonExistingOptions section, the visual feedback under the still-visible keyboard is what the reporter perceives as "Email not selected".

Now while the IME is still up, the user taps the back arrow. HeaderWithBackButton calls Keyboard.dismiss() then onBackButtonPress() synchronously in the same JS frame (src/components/HeaderWithBackButton/index.tsx#L247-L257), and onBackButtonPress runs Navigation.goBack(dynamicBackPath) immediately:

App/src/pages/workspace/DynamicWorkspaceInvitePage.tsx

Lines 256 to 263 in 81de6f5

	<HeaderWithBackButton
	title={translate('workspace.invite.invitePeople')}
	subtitle={policyName}
	onBackButtonPress={() => {
	clearErrors(route.params.policyID);
	Navigation.goBack(dynamicBackPath);
	}}
	/>

Keyboard.dismiss() only enqueues a native call to start the IME close animation — it does not await it. On the same frame, Navigation.goBack(dynamicBackPath) dispatches a goUp (Navigation.ts#L424-L501) that drives a stack-level POP/REPLACE transition. The screen begins unmounting while Android's InsetsAnimationController is still mid-animation on the soft keyboard, so when the animation callback fires after the host view is gone the controller is in the "cancelled" state and throws — crashing the app on Android 12 devices like the Xiaomi RedMi Note 10. The "tap email then back" sequence is the cleanest way to reproduce this because step 1 reliably keeps the IME up (persistTaps="always"), and step 2 fires dismiss + navigate back-to-back with no chance for the animation to settle.

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

Dismiss the keyboard the moment a row is selected in handleToggleSelection, mirroring the fix PR #90625 already applied to inviteUser, and the same proactive-dismiss pattern used in hideCurrencyPicker (commit 3de14a641f0, IOURequestStepAmount.tsx). Doing it on selection rather than on back-press means the IME animation has already settled by the time the user reaches for the back arrow, so the back navigation no longer overlaps an in-flight InsetsAnimationController. As a bonus, dismissing on selection also fixes the "Email not selected" confusion: the keyboard collapses so the user sees the row move into the top selected section and the "Next" button become enabled.

The change is two lines inside handleToggleSelection in DynamicWorkspaceInvitePage.tsx:

const handleToggleSelection = useCallback(
    (option: OptionData) => {
        Keyboard.dismiss();
        toggleSelection(option);
    },
    [toggleSelection],
);

This is safe across other callers because handleToggleSelection is only wired to this page's <SelectionListWithSections onSelectRow={...} />. It does not affect users navigating with a hardware keyboard (where there is no IME) since Keyboard.dismiss() is a no-op when no keyboard is shown, and keyboardShouldPersistTaps="always" continues to prevent focus loss from the input.

What alternative solutions did you explore? (Optional)

Adding Keyboard.dismiss() inside onBackButtonPress was rejected because HeaderWithBackButton already calls Keyboard.dismiss() synchronously right before invoking onBackButtonPress — a second sync call adds nothing and the race remains. Wrapping the back navigation in InteractionManager.runAfterInteractions(() => Navigation.goBack(...)) (the pattern used in ImportedMembersPage.tsx#L81) would also work, but it defers every back press, including the no-keyboard case, and is broader than necessary. Fixing it at the selection moment (when we know the IME is up because the user just tapped a row in a list that keeps it open) is the smallest change that eliminates the race for both the back path and any future code paths that navigate away from this screen.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-01 21:06:15 UTC.

Proposal

What is the root cause of that problem?

The workspace invite page is rebuilding its FlashList-backed sections while Android is also changing keyboard/layout state.

When a filtered invite row is pressed, SelectionListWithSections still runs the default multi-select behavior that clears the search input, updates focus, and then toggles the selected option. DynamicWorkspaceInvitePage then rebuilds its sections from the current search results and selected options. If the user presses the header back arrow immediately, the page navigates while the keyboard is still open and the user search/list layout work is still settling.

The attached log matches this path: React throws "Maximum update depth exceeded" in FlashList under BaseSelectionListWithSections and DynamicWorkspaceInvitePage. The screen crashes before the checkbox can visibly settle selected.

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

In DynamicWorkspaceInvitePage, make row selection and back navigation stable for this flow:

• Keep the selected invitee section stable while a row is being selected. Do not depend on transient filtered search rows for the selected item, and hide a duplicate userToInvite row once it is selected.
• Avoid clearing/rebuilding the search list in the same tap cycle. For this page, either pass shouldClearInputOnSelect={false} or defer clearing the input until after the selected row has committed.
• Keep the existing shouldUpdateFocusedIndex and shouldPreventAutoScrollOnSelect guards.
• In the header back handler, dismiss the keyboard and cancel the pending SEARCH_FOR_USERS request before Navigation.goBack(dynamicBackPath), matching the forward invite path.

This should stay limited to the workspace invite member flow and the shared selector/list stability needed by that flow. No backend/API change is needed.

What alternative solutions did you explore? (Optional)

Only adding the focus/auto-scroll guard props is not enough for current main because those props are already present. A broader FlashList rewrite would be higher risk than stabilizing this page's selection/search/back transition.

[melvin-bot]

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

[melvin-bot]

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

[oqildev]

What is the root cause of that problem?

This is a runaway re-render loop in the search-selector hook that backs the invite page, and it crashes the JS thread (hard crash on Android release builds).

DynamicWorkspaceInvitePage wires the list's onEndReached straight to onListEndReached from useSearchSelector:

• App/src/pages/workspace/DynamicWorkspaceInvitePage.tsx

  Line 282 in 309bfc7

  onEndReached={onListEndReached}

• which flows into the FlashList here:

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

  Line 444 in 309bfc7

  onEndReached={onEndReached}

And in the buggy build, onListEndReached bumps maxResults unconditionally every time it fires:

App/src/hooks/useSearchSelector/base.ts

Lines 214 to 216 in 309bfc7

	const onListEndReached = useDebounce(() => {
	setMaxResults((previous) => previous + maxResultsPerPage);
	}, CONST.TIMING.SEARCH_OPTION_LIST_DEBOUNCE_TIME);

When you type a full email that isn't an existing contact, the list holds a single userToInvite row. That content is shorter than the viewport, so FlashList fires onEndReached. onListEndReached increments maxResults, baseOptions recomputes into a fresh data array reference (the result set is still just the one row), the list re-renders, FlashList re-arms and fires onEndReached again → setMaxResults again → … This is exactly the infinite setState loop described in the PR that originally fixed it (#90918): "when there [are] fewer results in the list, the FlashList keeps executing its onEndReached … updating maxResults every time. This results in an infinite loop and causing the crash due to repeated calls of setState."

That loop also explains the "email not selected" symptom — the component is re-rendering continuously, so the tap's selection state never visually settles before the runaway updates take the JS thread down. Both reported symptoms are the same root cause.

Why it's live in 9.3.90-3 even though #90918 fixed it: the fix was reverted on staging by #91373 on May 22, and that revert is an ancestor of this build. The revert restored the unguarded onListEndReached and deleted the option-count guard that used to early-return when the visible result count was below maxResults (i.e. "nothing more to load"):

b9c42d935bd

The proper re-fix is still sitting on the fix/crash-on-loading-options branch (the "move hasMore outside of the Options type" work) and had not merged into main as of the June 1 build — I confirmed that commit is diverged from this SHA, not an ancestor. So between May 22 and now, this flow has had no guard at all.

This is Android-only in the report because that's where a runaway re-render loop reliably becomes a process crash (and where the TC was run — a low-end Xiaomi Redmi Note 10); the same loop exists on every platform.

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

Fix layer: hook — useSearchSelector/base.ts. The list and the page are innocent; they just forward onEndReached.

Put a guard back in onListEndReached so it stops growing maxResults once the current result set has nothing more to page in. Don't simply revert-the-revert — the count-based heuristic in #90918 is what got reverted (it was over-eager and broke legitimate "load more"). Gate the setMaxResults call on a real "has more results to fetch" signal, which is the approach the fix/crash-on-loading-options follow-up is already finalizing with a hasMore flag off the options builders (getValidOptions / getSearchOptions). Concretely: in onListEndReached, return early when !hasMore (or, until hasMore lands, when the total option count for the active context is < maxResults), and only then increment.

Edge cases this actually touches: the single-userToInvite case (typed email, no existing match) and any short result list — those must not grow maxResults. Genuine pagination (a full page of contacts where more exist server-side) must still increment, which is why the gate has to be a "more available" check, not just "is the list short".

What alternative solutions did you explore? (Optional)

• Guard at the FlashList layer (raise onEndReachedThreshold / debounce harder in the page). Rejected: it only widens the window between re-fires; the loop is driven by data getting a new reference every render while the content stays short, so the list keeps re-arming onEndReached regardless of threshold. The fix has to stop the state update at the source.
• Memoize baseOptions so the data reference is stable across renders. Rejected as the primary fix: it would mask this particular loop, but maxResults would still climb without bound on any short list, and the real contract — "don't ask for more when there's no more" — stays violated. Stabilizing references is a worthwhile separate cleanup, not the root-cause fix.
• Fix it on DynamicWorkspaceInvitePage only. Rejected: onListEndReached is shared by every consumer of useSearchSelector (search, share destination, attendees, member invite). fix: crash when searching results on participants step #90918's original report was actually the IOU Participants Step, not workspace invite — same hook, same crash. Fixing it in the hook covers all of them.

[KJ21-ENG]

Updating the proposal after L2 review: the attached log shows a FlashList maximum-update-depth crash in DynamicWorkspaceInvitePage, so the root cause and fix need to focus on stabilizing invite selection/search/back navigation rather than only adding guard props that current main already has.