[Due for payment 2026-03-19] [$250] Members - App crashes after importing members from spreadsheet

[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.33-1
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/13177080/test-cases/52085042
Email or phone of affected tester (no customers): applausetester+lamzxcxz1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11, Chrome | Samsung A15, Android 16
App Component: Workspace Settings

Action Performed:

1. Open the app or go to https://staging.new.expensify.com/
2. Sign up with a new Expensifail account.
3. Create a new Workspace.
4. Navigate to the Workspace > Members > More > Import spreadsheet
5. Drag and drop the attached file > Import > Import.

Expected Result:

When importing members from a spreadsheet, the app should process the data without crashing.

Actual Result:

The app crashes immediately after importing members from a spreadsheet.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

Bug7096160_1772850292454!Member_1.xlsx_-_Sheet1.csv

logs.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/~022030242129528464001
• Upwork Job ID: 2030242129528464001
• Last Price Increase: 2026-03-07

[melvin-bot]

Triggered auto assignment to @RachCHopkins (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

After importing members from a spreadsheet (Workspace > Members > Import spreadsheet), the app crashes with React error #185 ("Maximum update depth exceeded"). This affects both web (Chrome) and Android.

What is the root cause of that problem?

The crash is caused by an infinite re-render loop in ImportSpreadsheetConfirmModal. Here's the chain:

1. ImportMembersSpreadsheet API succeeds and merges {shouldFinalModalBeOpened: true, importFinalModal: {...}} into ONYXKEYS.IMPORTED_SPREADSHEET (src/libs/actions/Policy/Member.ts:156-192).

2. ImportSpreadsheetConfirmModal has a useEffect at line 32-46 that calls showConfirmModal() when isVisible becomes true.

3. showConfirmModal comes from useConfirmModal, which delegates to context.showModal from ModalContext.

4. showModal is not memoized (no useCallback) and calls setModalStack() which re-renders ModalProvider. The context value {showModal, closeModal} at line 95 is also not memoized, so every ModalProvider re-render creates new function references for all consumers.

5. Since showConfirmModal is in the useEffect dependency array and gets a new reference after each ModalProvider re-render, the effect fires again, calling showConfirmModal() again, which triggers another setModalStack() → another re-render → another new reference → infinite loop.

6. No deduplication occurs because showConfirmModal is called without an id parameter, so ModalProvider generates a new unique ID each time (line 49), bypassing the existing dedup check.

The lastAccessedWorkspacePolicyID rapid-fire setting visible in the logs is a symptom, not the cause — withPolicy HOC calls updateLastAccessedWorkspace(policyID) during render (withPolicy.tsx:93-95), so each iteration of the infinite loop triggers it.

Note: This likely affects all import flows (categories, tags, per-diem, transactions) since they all use ImportSpreadsheetConfirmModal.

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

1. Memoize showModal and closeModal in ModalProvider (src/components/Modal/Global/ModalContext.tsx): Wrap both functions with useCallback and memoize the context value with useMemo. This makes showConfirmModal stable across re-renders, preventing the useEffect from re-firing.

2. Pass a stable id to showConfirmModal in ImportSpreadsheetConfirmModal (src/components/ImportSpreadsheetConfirmModal.tsx): As a defense-in-depth measure, pass a constant id (e.g., "import-spreadsheet-confirm") so the deduplication logic in ModalProvider prevents duplicate modals even if the effect fires multiple times.

What alternative solutions did you explore? (Optional)

• Removing showConfirmModal from the dependency array: This would suppress the ESLint exhaustive-deps warning and mask the bug without fixing the underlying instability. Not recommended.
• Moving updateLastAccessedWorkspace into a useEffect in withPolicy.tsx: This would fix the symptom (rapid lastAccessedWorkspacePolicyID writes) but not the root cause (infinite loop in ImportSpreadsheetConfirmModal). Still worth doing separately as it's a render-time side effect anti-pattern.
• Using a ref to track whether showConfirmModal has already been called: This would work but is fragile — memoizing showModal is the cleaner fix.

---

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 - @ZhenjaHorbach (External)

[melvin-bot]

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

[MobileMage]

Proposal

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

After uploading a spreadsheet and clicking Import on the members import page, the app crashes immediately instead of importing the members or navigating to the confirmation page.

What is the root cause of that problem?

In ImportedMembersPage.tsx, the importMembers callback reads column data using spreadsheet?.data[membersEmailsColumn]. The optional chaining on spreadsheet?.data short-circuits to undefined when spreadsheet.data is nullish, but the immediately following bracket access [membersEmailsColumn] is not protected with optional chaining. Calling .map() on undefined throws a TypeError and crashes the app. Lines 98, 101, and 102 repeat the same pattern for the roles, submitsTo, and forwardsTo columns.

App/src/pages/workspace/members/ImportedMembersPage.tsx

Lines 97 to 102 in 43a57cf

	const membersEmails = spreadsheet?.data[membersEmailsColumn].map((email) => email);
	const membersRoles = membersRolesColumn !== -1 ? spreadsheet?.data[membersRolesColumn].map((role) => role) : [];
	const membersSubmitsToColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.SUBMIT_TO);
	const membersForwardsToColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.APPROVE_TO);
	const membersSubmitsTo = membersSubmitsToColumn !== -1 ? spreadsheet?.data[membersSubmitsToColumn].map((submitsTo) => submitsTo) : [];
	const membersForwardsTo = membersForwardsToColumn !== -1 ? spreadsheet?.data[membersForwardsToColumn].map((forwardsTo) => forwardsTo) : [];

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

Add optional chaining on the bracket accessor so that accessing a column array on a potentially-undefined data value degrades gracefully to undefined rather than throwing. The .map() calls are already guarded downstream via optional chaining on the result, so this is a minimal one-character fix per line.

- const membersEmails = spreadsheet?.data[membersEmailsColumn].map((email) => email);
- const membersRoles = membersRolesColumn !== -1 ? spreadsheet?.data[membersRolesColumn].map((role) => role) : [];
+ const membersEmails = spreadsheet?.data?.[membersEmailsColumn]?.map((email) => email);
+ const membersRoles = membersRolesColumn !== -1 ? spreadsheet?.data?.[membersRolesColumn]?.map((role) => role) : [];

And similarly for lines 101-102:

- const membersSubmitsTo = membersSubmitsToColumn !== -1 ? spreadsheet?.data[membersSubmitsToColumn].map((submitsTo) => submitsTo) : [];
- const membersForwardsTo = membersForwardsToColumn !== -1 ? spreadsheet?.data[membersForwardsToColumn].map((forwardsTo) => forwardsTo) : [];
+ const membersSubmitsTo = membersSubmitsToColumn !== -1 ? spreadsheet?.data?.[membersSubmitsToColumn]?.map((submitsTo) => submitsTo) : [];
+ const membersForwardsTo = membersForwardsToColumn !== -1 ? spreadsheet?.data?.[membersForwardsToColumn]?.map((forwardsTo) => forwardsTo) : [];

What alternative solutions did you explore? (Optional)

N/A

[jainam884]

Proposal

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

After importing workspace members from CSV, the app reaches the confirmation step and then crashes with React error #185 (maximum update depth exceeded) instead of showing a single success/failure confirmation modal and returning to Members safely.

What is the root cause of that problem?

The crash is a render loop in the confirmation-modal path.

When import completes, we merge importFinalModal into ONYXKEYS.IMPORTED_SPREADSHEET, then ImportSpreadsheetConfirmModal runs an effect that calls showConfirmModal().

showConfirmModal() delegates to ModalContext.showModal(). In ModalProvider, showModal is recreated each render and the provider value object is recreated too; calling showModal updates modal state (setModalStack), which re-renders provider, changes function identity, re-triggers the effect dependency, and opens again. Since no stable modal id is passed, dedup does not kick in and we keep stacking/opening until React throws #185.

App/src/libs/actions/Policy/Member.ts

Lines 156 to 192 in 43a57cf

	function updateImportSpreadsheetData(addedMembersLength: number, updatedMembersLength: number): OnyxData<typeof ONYXKEYS.IMPORTED_SPREADSHEET> {
	const onyxData: OnyxData<typeof ONYXKEYS.IMPORTED_SPREADSHEET> = {
	successData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.IMPORTED_SPREADSHEET,
	value: {
	shouldFinalModalBeOpened: true,
	importFinalModal: {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMembersSuccessfulDescription',
	promptKeyParams: {
	added: addedMembersLength,
	updated: updatedMembersLength,
	},
	},
	},
	},
	],
	failureData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.IMPORTED_SPREADSHEET,
	value: {
	shouldFinalModalBeOpened: true,
	importFinalModal: {
	titleKey: 'spreadsheet.importFailedTitle',
	promptKey: 'spreadsheet.importFailedDescription',
	},
	},
	},
	],
	};
	return onyxData;
	}

App/src/components/ImportSpreadsheetConfirmModal.tsx

Lines 32 to 46 in 43a57cf

	useEffect(() => {
	if (!isVisible || !titleText || !promptText || !spreadsheet?.importFinalModal) {
	return;
	}
	showConfirmModal({
	title: titleText,
	prompt: promptText,
	confirmText: translate('common.buttonConfirm'),
	shouldShowCancelButton: false,
	shouldHandleNavigationBack,
	onModalHide,
	}).then(() => {
	closeImportPageAndModal();
	});
	}, [isVisible, titleText, promptText, closeImportPageAndModal, onModalHide, shouldHandleNavigationBack, showConfirmModal, translate, spreadsheet?.importFinalModal]);

App/src/components/Modal/Global/ModalContext.tsx

Lines 45 to 66 in 43a57cf

	const showModal: ModalContextType['showModal'] = ({component, props, id, isCloseable = true}) => {
	// This is a promise that will resolve when the modal is closed
	let closeModalPromise: CloseModalPromiseWithResolvers | null = id ? modalPromisesStack.current?.[id] : null;
	const newModalId = id ?? String(modalIDRef.current++);
	if (!closeModalPromise) {
	// Create a new promise with resolvers to be resolved when the modal is closed
	const promiseWithResolvers = Promise.withResolvers<ModalStateChangePayload>();
	closeModalPromise = promiseWithResolvers;
	// New modal => update modals stack
	setModalStack((prevState) => ({
	...prevState,
	modals: [...prevState.modals, {component: component as React.FunctionComponent<ModalProps>, props, isCloseable, id: newModalId}],
	}));
	}
	modalPromisesStack.current[newModalId] = closeModalPromise;
	return closeModalPromise.promise;
	};

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

1. Stabilize modal context callbacks in ModalProvider:

• wrap showModal and closeModal in useCallback
• memoize provider value with useMemo

2. Add a stable modal id for this flow when calling showConfirmModal from ImportSpreadsheetConfirmModal (for example import-members-confirm-modal) so dedup logic prevents duplicate stack entries if the effect is retriggered.

3. Keep the useEffect dependency list exhaustive, but guard invocation to one open per isVisible=true cycle (small useRef latch reset when modal closes) to prevent accidental re-open from non-critical dependency changes.

This keeps scope tight to the modal stack/confirmation flow and avoids changing CSV parsing/validation behavior.

What alternative solutions did you explore? (Optional)

• Adding optional chaining in ImportedMembersPage (spreadsheet?.data?.[...]) is a good defensive hardening, but it does not explain the observed #185 render loop after importFinalModal merge and confirmation-route navigation.
• Removing showConfirmModal from effect dependencies would suppress the symptom but keep unstable callback behavior in modal context.

[ReaperOAK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.