[Due for payment 2026-05-22] [$250] Workspace- App crashes when invting user through invite button in Overview

[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: 9.3.62-1
Reproducible in staging?: Yes. Repro only in Honor x6b/ Android 14
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87089
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Honor x6b/ Android 14
App Component: Workspace Settings

Action Performed:

1. For a new account, complete onboarding with "Manage my team's expenses"

2. Tap on the workspace > Overview page

3. Tab the Invite member button

4. Enter and select an email address

5. Tap Next > Tap Invite

6. Tab the Invite member button

7. Add a email address > Next
   Result: App crashes

8. Launch app

9. Tap on the workspace > Overview page

10. Tab the Invite member button

11. Add a email address > Next
    Result: App crashes

12. Repeat step 8 to 11
    Result: App crashes

Expected Result:

User should land on the Invite message screen without any crash

Actual Result:

App crashes

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

dumpstate_log.txt

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022047784068996866005
• Upwork Job ID: 2047784068996866005
• Last Price Increase: 2026-05-08

[MelvinBot]

Proposal

What is the root cause of that problem?

This crash is device-specific (Honor x6b / Android 14 — a budget phone with limited RAM) and reproduces consistently after the first invite, including across app restarts. Based on code analysis, the most likely root cause is OOM (Out Of Memory) on the invite page due to the heavy data footprint of useSearchSelectorBase.

When DynamicWorkspaceInvitePage mounts, it initializes useSearchSelectorBase which simultaneously subscribes to 12+ large Onyx collections (all report attributes, all visible report actions, sorted report actions, all policies, all draft comments, all policy tags, login list, personal details, etc.) plus useOptionsList which materializes all reports and personal details into option arrays.

After the first successful invite, addMembersToWorkspace writes new optimistic Onyx data (expense chats, personal details, employee list entries, announce room updates). This data is persisted to disk. On the second invite attempt — and on all subsequent attempts even after restart — the invite page must load this now-larger dataset into memory, exceeding the device's available RAM and triggering an OOM kill.

This explains why: (1) the first invite works (smaller dataset), (2) the second crashes (dataset grew), and (3) restarting doesn't help (data is persisted in Onyx).

Alternative hypothesis considered

I also investigated whether PR #87089 (which changed getDynamicRouteAdaptedState for dynamic route navigation) could cause a navigation state corruption crash. However, getDynamicRouteAdaptedState is only called during page refresh/deep-link/app startup — not during normal in-app Navigation.navigate() calls (linkTo uses plain getStateFromPath). Since the crash occurs during normal in-app navigation (tapping the invite button), this path is unlikely to be the cause.

I also checked for potential JS exceptions in createDynamicRoute (throws on duplicate query params) and a race condition in WorkspaceInviteMessageComponent (useEffect with [isOnyxLoading] dependency could navigate back prematurely if Onyx cache is warm). Neither fully explains the device-specific crash pattern.

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

The invite page (DynamicWorkspaceInvitePage) should defer or lazy-load the heavy useSearchSelectorBase subscriptions. Specifically:

1. Gate useSearchSelectorBase initialization behind shouldInitialize — the hook already accepts a shouldInitialize param. Ensure it is false until the screen transition completes and the user actually needs the search results, preventing all 12+ Onyx subscriptions from firing at mount time.
2. Consider whether all subscriptions are necessary for the workspace invite use case — the invite page only needs personal details and the login list for email search. It likely doesn't need all report actions, sorted actions, report attributes, or policy tags. A lighter-weight hook or filtered subscription could dramatically reduce memory usage.

What alternative solutions did you explore? (Optional)

• Device-specific fix: Since this only reproduces on a specific budget Android device, we could consider adding memory-aware loading thresholds. However, this doesn't address the underlying excessive memory usage which likely affects performance on all lower-end devices even if it doesn't crash them.
• Pagination of Onyx data: Loading Onyx collections in batches rather than all at once would help but requires deeper architectural changes.

Note: Without access to the actual crash logs from the attached dumpstate_log.txt or Sentry crash reports, this analysis is at medium confidence. The device-specific reproduction pattern and code-level evidence strongly point to OOM, but confirming would require examining the crash signal (OOM killer, native crash, or unhandled JS exception) from the device logs.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

The app crashes on the second attempt to invite a user to a workspace via the Overview invite button, and the crash persists across app restarts.

What is the root cause of that problem?

inviteUser() in DynamicWorkspaceInvitePage calls setWorkspaceInviteMembersDraft() (async Onyx.set) then immediately calls Navigation.navigate() without awaiting the write. On the first invite, the Onyx key has never been set, so useOnyx() in WorkspaceInviteMessageComponent reports isOnyxLoading = true while loading — giving the async write time to complete. On the second invite, the key is already cached as {} (from the prior invite's cleanup), so useOnyx() returns it synchronously with isOnyxLoading = false. The useEffect at line 122 sees an empty draft, evaluates isEmptyObject({}) as true, and immediately calls Navigation.goBack() during mount — before the new Onyx.set has been processed. This mount-then-immediate-goBack causes a native navigation stack crash, especially on low-end Android devices where the async write takes longer.

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

1. In Member.ts, return the Promise from Onyx.set:

function setWorkspaceInviteMembersDraft(policyID: string, invitedEmailsToAccountIDs: InvitedEmailsToAccountIDs) {
    return Onyx.set(`${ONYXKEYS.COLLECTION.WORKSPACE_INVITE_MEMBERS_DRAFT}${policyID}`, invitedEmailsToAccountIDs);
}

2. In DynamicWorkspaceInvitePage, await the draft write before navigating:

const inviteUser = useCallback(async () => {
    // ... existing logic ...
    await setWorkspaceInviteMembersDraft(route.params.policyID, invitedEmailsToAccountIDs);
    Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.WORKSPACE_INVITE_MESSAGE.path));
}, [route.params.policyID, selectedOptions]);

What alternative solutions did you explore? (Optional)

This differs from MelvinBot's proposal, which attributes the crash to OOM from heavy useSearchSelectorBase subscriptions. That theory doesn't explain why the first invite always succeeds (the same subscriptions fire both times) or why the crash is deterministic rather than probabilistic. The race condition between the async Onyx write and synchronous navigation precisely explains the first-succeeds / second-crashes pattern: the Onyx cache state changes after the first invite, eliminating the isOnyxLoading grace period that masked the timing bug. The fix here is minimal (two lines changed) and targets the actual sequencing defect rather than optimizing memory usage speculatively.

[wildan-m]

Proposal

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

On a Honor x6b (Android 14, a low-RAM budget phone), the Workspace Overview "Invite member" flow crashes on every attempt after the first successful invite, and the crash persists across app restarts. The first invite completes normally; every subsequent attempt — even after re-launching the app — crashes at the step where the user taps "Next" from the invite selector to the invite message screen.

What is the root cause of that problem?

The crash is a memory spike triggered by work done when the invite selector is opened the second time. Two facts about the repro pinpoint the cause:

1. It only fails on the second attempt and later, and persists after restart. This tells us the trigger is data that was newly persisted to Onyx during the first addMembersToWorkspace call — specifically, a new expense chat report, a new report action for the welcome message, a new entry in the policy's employee list, and a new personal details entry for the invited user. All four are written as optimistic data in buildAddMembersToWorkspaceOnyxData and survive across restarts.

2. It only fails on a low-RAM device. This tells us it is a memory-pressure regression, not a logic bug — other accounts/devices reach the same state without crashing.

The dominant memory cost when the invite selector opens comes from OptionListContextProvider, which maintains an in-memory option list for every report and every personal details entry in the store. When addMembersToWorkspace writes its optimistic data, the personalDetails dependency of this effect changes:

App/src/components/OptionListContextProvider.tsx

Lines 253 to 333 in 0f9bba8

	*/
	useEffect(() => {
	// there is no need to update the options if the options are not initialized
	if (!areOptionsInitialized.current) {
	return;
	}
	if (!personalDetails) {
	return;
	}
	// Handle initial personal details load. This initialization is required here specifically to prevent
	// UI freezing that occurs when resetting the app from the troubleshooting page.
	if (!prevPersonalDetails) {
	const {personalDetails: newPersonalDetailsOptions, reports: newReports} = createOptionList(
	personalDetails,
	privateIsArchivedMap,
	reports,
	allPolicies,
	reportAttributes?.reports,
	);
	setOptions((prevOptions) => ({
	...prevOptions,
	personalDetails: newPersonalDetailsOptions,
	reports: newReports,
	}));
	return;
	}
	const newReportOptions: Array<{
	replaceIndex: number;
	newReportOption: SearchOption<Report>;
	}> = [];
	for (const accountID of Object.keys(personalDetails)) {
	const prevPersonalDetail = prevPersonalDetails?.[accountID];
	const personalDetail = personalDetails[accountID];
	if (prevPersonalDetail && personalDetail && isEqualPersonalDetail(prevPersonalDetail, personalDetail)) {
	continue;
	}
	for (const report of Object.values(reports ?? {})) {
	if (!report) {
	continue;
	}
	const isParticipant = accountID in (report.participants ?? {});
	const isOwnerOfSelfDM = isSelfDM(report) && report?.ownerAccountID === Number(accountID);
	if (!isParticipant && !isOwnerOfSelfDM) {
	continue;
	}
	const privateIsArchived = privateIsArchivedMap[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`];
	const policy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const newReportOption = createOptionFromReport(report, personalDetails, privateIsArchived, policy, reportAttributes?.reports, {
	showPersonalDetails: true,
	});
	const replaceIndex = options.reports.findIndex((option) => option.reportID === report.reportID);
	newReportOptions.push({
	newReportOption,
	replaceIndex,
	});
	}
	}
	// since personal details are not a collection, we need to recreate the whole list from scratch
	const newPersonalDetailsOptions = createOptionList(personalDetails, privateIsArchivedMap, reports, allPolicies, reportAttributes?.reports).personalDetails;
	setOptions((prevOptions) => {
	const newOptions = {...prevOptions};
	newOptions.personalDetails = newPersonalDetailsOptions;
	for (const newReportOption of newReportOptions) {
	newOptions.reports[newReportOption.replaceIndex] = newReportOption.newReportOption;
	}
	return newOptions;
	});
	// This effect is used to update the options list when personal details change so we ignore all dependencies except personalDetails
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [personalDetails]);

The effect runs, and inside it, this line unconditionally rebuilds the entire option list from scratch — every personal details entry and every report — every time personalDetails changes, regardless of how small the change was:

App/src/components/OptionListContextProvider.tsx

Lines 319 to 320 in 0f9bba8

	// since personal details are not a collection, we need to recreate the whole list from scratch
	const newPersonalDetailsOptions = createOptionList(personalDetails, privateIsArchivedMap, reports, allPolicies, reportAttributes?.reports).personalDetails;

createOptionList walks Object.values(reports) and Object.keys(personalDetails) and calls createOptionFromReport / createOptionFromPersonalDetail for every entry. Each call allocates a fresh SearchOption object holding denormalized display fields (text, alternateText, icons, search terms, login, etc.). On a busy workspace, the personal details map alone has thousands of entries; the reports map is similarly large.

So the sequence on the second invite is:

1. First invite succeeds → addMembersToWorkspace optimistic data lands → personalDetails changes.
2. The effect at line 253 fires and calls createOptionList with the full personalDetails + reports → a large new personalDetails option array is allocated and set into context state.
3. User taps Invite again → DynamicWorkspaceInvitePage mounts → its useOptionsList hook copies the context value into local state (setInternalOptions(optionsList) in useOptionsList, which holds a second full copy per subscriber).
4. The user taps Next → WorkspaceInviteMessageComponent mounts. Its useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST) and getPersonalDetailsForAccountIDs(Object.values(invitedEmailsToAccountIDsDraft), allPersonalDetails) traverse the full personal details again, and ReportActionAvatars loads avatars for the invited account IDs.

The first-attempt path never hits step 2, because there is no optimistic personal-details change between mount and Next. The second-attempt path always hits step 2, because the first invite's optimistic write is what triggered the full rebuild. On a low-RAM device, the combination of the freshly rebuilt option list (still held by context state + internal copies) plus the new allocations during the Next transition exceeds the heap and Android kills the app. The state is persisted, so relaunching and opening the invite flow repeats the same sequence and crashes again.

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

Stop rebuilding the entire option list from scratch when only a few personal details entries have changed. The effect at OptionListContextProvider.tsx line 253–333 already knows which personal details entries are new or different — it iterates them at line 287 to find reports that need re-processing. Extend that same delta-based update to the personalDetails slice of the option list:

• Keep a map keyed by accountID of the previous personalDetails options (similar to how buildUpdatedReportsMap already keys reports by reportID in the reports-change effect at line 131–160).
• When the effect runs, iterate only the accountIDs whose personalDetails entry actually changed (using the existing isEqualPersonalDetail comparison at line 47–51). For each changed accountID, call createOptionFromPersonalDetail (or its equivalent inside createOptionList) for that single entry and update the map. Drop entries for accountIDs removed from personalDetails.
• Produce the new personalDetails option array from Array.from(updatedPersonalDetailsMap.values()), mirroring the pattern already in use for reports.
• Replace the full-rebuild call at line 319–320 with this delta path. The "initial load" branch at line 266–280 (where prevPersonalDetails is not yet populated) is the only case that still needs the full createOptionList call — keep that unchanged.

With this change, adding one invited member touches one accountID and updates one option array entry, instead of allocating a fresh option for every personal details entry. The affected report options are already handled by the delta loop at line 287–317, so no additional work is needed there.

To verify the fix addresses the crash pattern specifically, reproduce on a low-RAM Android device or with Android Studio's memory profiler set to a constrained heap: confirm that opening the invite selector after a successful invite allocates bytes proportional to the added entry rather than proportional to the full personal details map. The reporter's attached dumpstate_log.txt should show an OOM signal that disappears after the fix.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88754-option-list-delta?expand=1

What alternative solutions did you explore? (Optional)

• Memoizing useOptionsList's internal optionsList copy so that subscribers share a single reference instead of each holding a personal copy (setInternalOptions(optionsList) at line 408 of OptionListContextProvider.tsx). This reduces per-subscriber duplication but does not address the root allocation caused by the full-rebuild in the effect; it is a complementary improvement rather than a fix for this specific crash, so I did not pursue it here.

• Deferring the OptionListContextProvider update until after the invite flow's navigation transition completes (wrapping the setOptions calls in InteractionManager.runAfterInteractions). This lowers the chance of a frame-time collision but leaves the same total memory footprint on the heap, so it does not actually prevent the OOM on a constrained device — it just shifts when it happens.

[wildan-m]

Proposal updated — added compare branch with implementation.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.