[$250] Rules - "Import" button is disabled when attempts to import merchant rules while offline

[applause-bot]

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.4.43-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96522
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, iPhone 13 / iOS 27 Beta, Samsung Galaxy A52 / Android 14
App Component: Workspace Settings

Action Performed:

Preconditions:

• Signed in to gmail account that has at least one workspace
• Enable category and rules in more features
• Download the merchant rules csv (attached below)

Steps:

1. Go to workspace settings > Rules.
2. Click More > Import merchant rules.
3. Upload the merchant-rules-test.csv file.
4. Map the columns: Merchant → "Merchant is", Category → "Updated category", Description → "Updated description", then click Import.
5. Import the same CSV again, but this time map Description → "Ignore" (keep Merchant → "Merchant is" and Category → "Updated category").
6. go offline
7. Repeat the second import from Tests step 5 (same CSV, Description → "Ignore")
8. Click "import" button

Expected Result:

"Import" button should be active, so the modal "No merchant rules have been added, since they all already exist. 2 categories were skipped because they don't exist in this workspace." still appears while offline

Actual Result:

"Import" button is disabled when attempts to import merchant rules while offline

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7215089_1784774866654.bandicam_2026-07-23_09-34-40-668.mp4

merchant-rules-test.csv

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7215089

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080144374275126780
• Upwork Job ID: 2080144374275126780
• Last Price Increase: 2026-07-23

Issue Owner

Current Issue Owner: @justinpersaud

[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/e02a6d212bf7ce03c62b6059bcee03fc185977970c741c747181acffe7b671d0

https://platform.applause.com/services/links/v1/external/3511c58237554c29f7a5ca0cf79e27bdddedccbf203033946d8ee6e22b8eaf4e

[MelvinBot]

Proposal

What is the root cause of that problem?

The Import button lives in the shared ImportSpreadsheetColumns component, which hard-disables it whenever the device is offline:

src/components/ImportSpreadsheetColumns.tsx:127 → isDisabled={isOffline}

This blanket guard exists because most spreadsheet imports need a live server round-trip to build their confirmation modal. But the merchant-rules flow has a client-side-only path: when every parsed row is a duplicate of an existing rule and/or references a category that doesn't exist, ImportedMerchantRulesPage.importRules short-circuits and builds the "No merchant rules have been added…" modal locally, without calling the API.

So in the reported scenario (re-importing the same CSV where all rows already exist), no network is required — yet the offline guard on the shared button still blocks it, so the modal never appears offline. This is the exact mismatch QA hit.

Why the button can't simply be enabled offline for all cases

When there are net-new rules to import, merchant rules go through importMerchantRulesSpreadsheet, which uses API.makeRequestWithSideEffects (Rules.ts:307) to get the server result synchronously and render the modal. That genuinely cannot complete offline. The same is true for the other consumers of this shared component (categories, tags, members, per diem, company cards, wallet transactions), which is why disabling offline is correct for them.

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

Stop applying the offline guard unconditionally in the shared component, and let the merchant-rules page opt out:

1. In ImportSpreadsheetColumns, add a prop such as shouldDisableButtonWhenOffline (default true, preserving today's behavior for every other importer) and use it in place of the hard-coded isOffline at line 127.
2. In ImportedMerchantRulesPage, pass the new prop so the button stays active offline. The existing all-skipped short-circuit already renders the confirmation modal with no network call.

Design decision for the C+ team: what should happen offline when the CSV does contain net-new rules? With the button enabled, that path hits makeRequestWithSideEffects and would surface the generic "import failed" modal offline. Options: (a) accept that as-is, or (b) keep it stricter and only enable the button once the page determines all rows would be skipped. (a) is the smaller change and matches the reported expectation; (b) is cleaner UX but requires parsing before the button becomes enabled.

What alternative solutions did you explore? (Optional)

Making the entire merchant-rules import offline-capable (optimistic Onyx write + queued request instead of a side-effect request) would fully align it with the offline-first architecture, but that is a larger refactor of both the action and the modal flow and is out of scope for this bug.

---

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

[abbasifaizan70]

Proposal

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

When offline and re-importing a merchant rules CSV whose rows all already exist as rules on the workspace (so nothing new would actually be created), the "Import" button is disabled. It should stay enabled, because in this case the "No merchant rules have been added, since they all already exist..." result is computed entirely client-side and never requires a network call.

What is the root cause of that problem?

ImportedMerchantRulesPage's importRules builds the rules from the mapped spreadsheet, and when every row turns out to be a duplicate of an existing rule (or references an unknown category), it skips the API call entirely and builds the final modal locally:

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 289 to 299 in 4bb1d01

	setIsImportingRules(true);
	// When every row was skipped (duplicate rules and/or unknown categories), skip the API call and confirm that nothing was added
	const importFinalModal: ImportFinalModal =
	Object.keys(rules).length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)
	? {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
	promptKeyParams: {rules: 0, duplicates: skippedDuplicateCount, invalidCategories: invalidCategoryNames.size},
	}
	: await importMerchantRulesSpreadsheet(policyID, rules, invalidCategoryNames.size);
	const didShowImportFinalModal = await showImportSpreadsheetConfirmModal(importFinalModal, {shouldHandleNavigationBack: false});

This branch never touches the network, so it can safely run while offline. However, the "Import" button itself lives in the shared ImportSpreadsheetColumns component, which disables it purely based on global connectivity, with no awareness of whether the specific import attempt needs the network:

App/src/components/ImportSpreadsheetColumns.tsx

Lines 123 to 132 in 4bb1d01

	<Button
	text={translate('common.import')}
	onPress={importFunction}
	isLoading={isButtonLoading}
	isDisabled={isOffline}
	pressOnEnter
	success
	large
	/>
	</OfflineWithFeedback>

Because isDisabled={isOffline} is unconditional, the button is greyed out even for the all-duplicates case that importRules is fully able to resolve offline. (This is distinct from the "some rows are genuinely new rules" case, which does call importMerchantRulesSpreadsheet via API.makeRequestWithSideEffects, and that call really does require connectivity — so the button shouldn't be unconditionally enabled offline either.)

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

The fix should let ImportedMerchantRulesPage tell the shared button whether the current column mapping would produce an entirely local (no-network) result, rather than having ImportSpreadsheetColumns blindly disable on isOffline for every import flow that reuses it (Categories/Tags/PerDiem/Company Cards imports still genuinely require the network for every row, so their behavior shouldn't change).

1. In ImportSpreadsheetColumns.tsx, add an optional prop (e.g. isOfflineImportAllowed, default false) and use it to soften the disable condition:

App/src/components/ImportSpreadsheetColumns.tsx

Lines 123 to 132 in 4bb1d01

	<Button
	text={translate('common.import')}
	onPress={importFunction}
	isLoading={isButtonLoading}
	isDisabled={isOffline}
	pressOnEnter
	success
	large
	/>
	</OfflineWithFeedback>

isDisabled={isOffline && !isOfflineImportAllowed}

Leaving the prop's default as false preserves today's behavior for every other page that reuses this component.

2. In ImportedMerchantRulesPage.tsx, hoist the row-processing loop that currently lives inside importRules (src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx#L236-L287, which builds rules, skippedDuplicateCount, and invalidCategoryNames) into a small helper function that both importRules and a new useMemo can call, so the logic isn't duplicated. Use that memoized result (recomputed from spreadsheet, policy?.rules?.codingRules, and policyCategories) to derive a boolean, e.g. wouldSkipNetworkCall = rules.length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0), mirroring the exact condition already used at src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx#L292. Pass this as isOfflineImportAllowed={wouldSkipNetworkCall} to ImportSpreadsheetColumns (src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx#L334-L342).

With this change, the "Import" button stays enabled offline only when the current mapping would resolve to the fully-local "already exists" outcome (matching the issue's expected result), while it correctly remains disabled offline whenever the mapping would actually create new rules and therefore needs the IMPORT_MERCHANT_RULES_SPREADSHEET network call.

[MobileMage]

Proposal

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

When re-importing a merchant rules CSV whose rows are all duplicates of existing rules (with unknown categories skipped), the import is resolved entirely on the client and shows a "nothing was added" confirmation modal without any API call. But when the user goes offline, the Import button on the column-mapping page is disabled, so this fully-offline-capable path can't be reached at all.

What is the root cause of that problem?

ImportedMerchantRulesPage (added in PR #96522) has two outcomes inside importRules. If every parsed row is skipped (duplicate rules and/or categories that don't exist on the workspace), it builds the final modal locally and never touches the network; only when there are genuinely new rules does it call importMerchantRulesSpreadsheet, which fires IMPORT_MERCHANT_RULES_SPREADSHEET via API.makeRequestWithSideEffects. The local branch is here in src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx:

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 291 to 298 in 4bb1d01

	const importFinalModal: ImportFinalModal =
	Object.keys(rules).length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)
	? {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
	promptKeyParams: {rules: 0, duplicates: skippedDuplicateCount, invalidCategories: invalidCategoryNames.size},
	}
	: await importMerchantRulesSpreadsheet(policyID, rules, invalidCategoryNames.size);

However, the page renders its footer through the shared ImportSpreadsheetColumns component, and that component unconditionally disables the Import button while offline:

App/src/components/ImportSpreadsheetColumns.tsx

Lines 123 to 127 in 4bb1d01

	<Button
	text={translate('common.import')}
	onPress={importFunction}
	isLoading={isButtonLoading}
	isDisabled={isOffline}

<Button
    text={translate('common.import')}
    onPress={importFunction}
    isLoading={isButtonLoading}
    isDisabled={isOffline}

That blanket isDisabled={isOffline} is the right default for every other consumer of this component (categories, tags, members, per diem, multi-level tags), because their importFunction always resolves through a side-effect API request that cannot be queued offline — makeRequestWithSideEffects requests are not persisted, so there is nothing useful the button could do. Merchant rules import is the first consumer with a client-only outcome, and the shared component has no way to opt out, so the duplicate-detection path that PR #96522's own QA steps expect to work offline is unreachable. Notably, even the online-API branch is offline-safe by construction: importMerchantRulesSpreadsheet wraps the request in a try/catch and resolves to getImportFailedFinalModal() on any failure, so pressing Import offline with new rows would show the standard "import failed" modal rather than hanging.

I reproduced this on the merchant rules column-mapping page. With the columns mapped and the Import button live, dropping the connection greys the button out and it stops responding, so the "No merchant rules have been added..." confirmation never appears. Nothing failed underneath: the parsed spreadsheet and the column mapping are still held correctly, the page renders every row and its mapped field, and no error is raised at any point. No import request is attempted either, so the press is blocked before any handler runs. That points straight at the blanket isDisabled={isOffline} on the footer button in the shared src/components/ImportSpreadsheetColumns.tsx (L127, fed by the useNetwork() call on L70) that ImportedMerchantRulesPage renders. The page itself has no merchant-rules-specific offline gate, so the shared component is the only thing turning the button off, exactly as the root cause above describes.

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

Add an opt-out prop to ImportSpreadsheetColumns, defaulting to the current behavior so no other import flow changes, and disable the merchant rules page from the blanket offline gate. Following the naming precedent of shouldDisableConfirmButtonWhenOffline in ConfirmContent:

// ImportSpreadsheetColumns.tsx
shouldDisableButtonWhenOffline = true,
...
isDisabled={isOffline && shouldDisableButtonWhenOffline}

Then in ImportedMerchantRulesPage pass shouldDisableButtonWhenOffline={false} to ImportSpreadsheetColumns. With this, the all-skipped path works fully offline and shows the expected "No merchant rules have been added… 2 categories were skipped…" modal, matching the QA expectation. When there are new rules while offline, the existing try/catch in importMerchantRulesSpreadsheet (src/libs/actions/Policy/Rules.ts) already resolves to the failure modal, so the button never spins forever; if we want to avoid the doomed network attempt entirely, we can add a cheap early return of getImportFailedFinalModal() in importRules when isOffline and rules is non-empty — the page already imports useNetwork for its category refetch, so isOffline is available at no cost. This change is safe for all other callers because the prop defaults to true, preserving today's disabled-offline behavior for every other spreadsheet import.

What alternative solutions did you explore? (Optional)

We considered computing upfront (via a memoized pass over the spreadsheet rows and policy.rules.codingRules) whether the import would be fully client-side and disabling the button offline only when an API call would actually be needed (isDisabled={isOffline && hasNewRules}). That duplicates the entire row-parsing/normalization logic outside importRules and has to re-run on every column-mapping change, which is disproportionate for a button state; the simple opt-out prop plus the existing failure-modal fallback covers both offline cases with far less complexity.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-23 04:17:45 UTC.

Proposal

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

On workspace Rules > Import merchant rules, the Import button on the column-mapping screen is hard-disabled while offline. So re-importing a spreadsheet whose rows all already exist can't show the "No merchant rules have been added, since they all already exist…" confirmation — even though, after PR #96522, that exact path needs no network at all.

What is the root cause of that problem?

1. The Import button is rendered by the shared ImportSpreadsheetColumns component, which disables it whenever the device is offline:

   App/src/components/ImportSpreadsheetColumns.tsx

   Lines 123 to 131 in 4bb1d01

   	<Button
   	text={translate('common.import')}
   	onPress={importFunction}
   	isLoading={isButtonLoading}
   	isDisabled={isOffline}
   	pressOnEnter
   	success
   	large
   	/>

2. That disable is intentional and load-bearing. It shipped with the component in PR #47827 (the original CSV import flow), and every import screen's import function awaits a live server response via API.makeRequestWithSideEffects — merchant rules:

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

   Lines 303 to 311 in 4bb1d01

   	try {
   	// We need the server result immediately so the initiating page can show the final confirmation modal
   	// without storing transient modal state in Onyx.
   	// eslint-disable-next-line rulesdir/no-api-side-effects-method
   	const response = await API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.IMPORT_MERCHANT_RULES_SPREADSHEET, parameters);
   	return response?.jsonCode === CONST.JSON_CODE.SUCCESS ? importFinalModal : getImportFailedFinalModal();
   	} catch {
   	return getImportFailedFinalModal();
   	}

   , and the same pattern in Category.ts#L923, Tag.ts#L250, members, per-diem, company cards, and wallet transactions. Side-effect commands are processed immediately and are never persisted to the offline queue:

   App/src/libs/API/index.ts

   Lines 261 to 271 in 4bb1d01

   	function makeRequestWithSideEffects<TCommand extends SideEffectRequestCommand, TKey extends OnyxKey>(
   	command: TCommand,
   	apiCommandParameters: ApiRequestCommandParameters[TCommand],
   	onyxData: OnyxData<TKey> = {},
   	): Promise<void | Response<TKey>> {
   	Log.info('[API] Called API makeRequestWithSideEffects', false, buildLogParams(command, apiCommandParameters ?? {}));
   	const request = prepareRequest(command, CONST.API_REQUEST_TYPE.MAKE_REQUEST_WITH_SIDE_EFFECTS, apiCommandParameters, onyxData);
   	// Return a promise containing the response from HTTPS
   	return processRequest(request, CONST.API_REQUEST_TYPE.MAKE_REQUEST_WITH_SIDE_EFFECTS);
   	}

3. PR #96522 (the regression-test PR linked in this issue) changed that equation for merchant rules only: rows are now deduped client-side against the policy's existing codingRules (

   App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

   Lines 226 to 233 in 4bb1d01

   	const seenRuleKeys = new Set(
   	Object.values(policy?.rules?.codingRules ?? {})
   	.filter((rule) => rule.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && rule.filters?.right)
   	.map(getRuleContentKey),
   	);
   	let skippedDuplicateCount = 0;
   	const categoryLookup = buildImportedCategoryLookup(policyCategories);

   , skip at

   App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

   Lines 279 to 284 in 4bb1d01

   	const ruleKey = getRuleContentKey(rule);
   	if (seenRuleKeys.has(ruleKey)) {
   	skippedDuplicateCount++;
   	continue;
   	}
   	seenRuleKeys.add(ruleKey);

   ) and unknown categories are dropped client-side (

   App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

   Lines 248 to 261 in 4bb1d01

   	// and reported in the final modal rather than stored as a category the rule could never apply
   	const categoryCell = getCellValue(categoryColumn, rowIndex);
   	const category = categoryCell ? (categoryLookup.get(categoryCell.toLowerCase()) ?? '') : '';
   	if (categoryCell && !category) {
   	invalidCategoryNames.add(categoryCell.toLowerCase());
   	}
   	const tag = normalizeImportedTag(getCellValue(tagColumn, rowIndex), !!policy?.hasMultipleTagLists);
   	const comment = getCellValue(commentColumn, rowIndex);
   	const reimbursable = parseCsvBooleanValue(getCellValue(reimbursableColumn, rowIndex));
   	const billable = parseCsvBooleanValue(getCellValue(billableColumn, rowIndex));
   	// Skip rows where every action cell is empty since the resulting rule would never change anything
   	if (!updatedMerchant && !category && !tag && !comment && reimbursable === undefined && billable === undefined) {
   	continue;

   ). When every row is skipped, the confirmation modal is built locally and no API call is made:

   App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

   Lines 289 to 298 in 4bb1d01

   	setIsImportingRules(true);
   	// When every row was skipped (duplicate rules and/or unknown categories), skip the API call and confirm that nothing was added
   	const importFinalModal: ImportFinalModal =
   	Object.keys(rules).length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)
   	? {
   	titleKey: 'spreadsheet.importSuccessfulTitle',
   	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
   	promptKeyParams: {rules: 0, duplicates: skippedDuplicateCount, invalidCategories: invalidCategoryNames.size},
   	}
   	: await importMerchantRulesSpreadsheet(policyID, rules, invalidCategoryNames.size);

4. The structural cause: the shared component equates "offline" with "cannot import". That was true for every flow until #96522 made merchant-rules import completable fully client-side in the all-skipped case — the shared button knows nothing about that, so the new local path is unreachable offline.
5. Substituting the repro: step 5 (online) imported the comment-less rule variants, so in step 7 every re-parsed row is either key-identical to an existing rule (duplicate) or has an unknown category and no remaining actions (skipped). rules ends up empty and the local branch would show exactly the expected text via importMerchantRulesSuccessfulDescription (

   App/src/languages/en.ts

   Lines 1247 to 1253 in 4bb1d01

   	importMerchantRulesSuccessfulDescription: ({rules, duplicates = 0, invalidCategories = 0}: {rules: number; duplicates?: number; invalidCategories?: number}) => {
   	const invalidCategoriesNote =
   	invalidCategories > 0
   	? ` ${invalidCategories === 1 ? '1 category was' : `${invalidCategories} categories were`} skipped because ${invalidCategories === 1 ? "it doesn't" : "they don't"} exist in this workspace.`
   	: '';
   	if (rules === 0) {
   	return `${duplicates > 0 ? 'No merchant rules have been added, since they all already exist.' : 'No merchant rules have been added.'}${invalidCategoriesNote}`;

   ). The disabled button is the only blocker: the confirm modal itself is fully local, and all platforms are hit identically because the component is shared.

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

Scope the offline-disable to imports that actually need the network:

1. ImportSpreadsheetColumns: add an optional canImportOffline prop (default false) and change line 127 to:

isDisabled={isOffline && !canImportOffline}

2. ImportedMerchantRulesPage: extract the existing row-parsing/dedup loop (L226–L287) into a pure helper returning {rules, skippedDuplicateCount, invalidCategoryNames}; call it from importRules (behavior unchanged) and from a useMemo to derive whether the import completes locally, then:

const isImportFullyLocal = isEmptyObject(rules) && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0);
// …
<ImportSpreadsheetColumns … canImportOffline={isImportFullyLocal} />

(rule keys/created stay assigned at press time so render remains pure). Offline + all rows skippable → button active → local modal, exactly the expected result. Offline + any genuinely new rule → button stays disabled, preserving the intended #47827 behavior. Regression safety: the prop defaults to false, so the other seven import screens and all online behavior are byte-for-byte unchanged.

Why the simple fix fails: deleting isDisabled={isOffline} (or enabling it unconditionally for merchant rules) routes offline presses into await API.makeRequestWithSideEffects — side-effect commands bypass the persisted offline queue (link in step 2), so the request rejects immediately and the catch returns the "Import failed" modal (Rules.ts#L309-L311). That turns a clear disabled state into a false failure on all eight consumers of this component:

App/src/pages/workspace/categories/ImportedCategoriesPage.tsx

Line 205 in 4bb1d01

<ImportSpreadsheetColumns

, ImportedTagsPage.tsx#L159, ImportedMultiLevelTagsPage.tsx#L72, ImportedMembersPage.tsx#L289, ImportedPerDiemPage.tsx#L175, CompanyCardsImportedPage.tsx#L235, TransactionsImportedPage.tsx#L155, and merchant rules itself whenever the spreadsheet contains one new rule.

What alternative solutions did you explore? (Optional)

1. Remove isDisabled={isOffline} in the shared component — regresses the other seven flows as proven above.
2. Pass canImportOffline unconditionally for merchant rules and short-circuit in importRules (offline + non-empty rules → show the failed modal without firing the doomed request). Simpler, but a real offline import then presses into an instant "Import failed" — the memo-gated headline keeps the established disabled-offline pattern wherever the network is genuinely required.
3. Convert ImportMerchantRulesSpreadsheet into an optimistic Write command (after #96522 the modal params are already computed client-side; the response only gates success/failure) — the offline-first endgame, but far larger than this bug warrants.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-23 04:53:53 UTC.

Proposal

What is the root cause of that problem?

ImportSpreadsheetColumns unconditionally disables its shared Import button whenever the app is offline.

App/src/components/ImportSpreadsheetColumns.tsx

Lines 117 to 133 in 4bb1d01

	<FixedFooter addBottomSafeAreaPadding>
	<OfflineWithFeedback
	shouldDisplayErrorAbove
	errors={errors}
	errorRowStyles={styles.mv2}
	>
	<Button
	text={translate('common.import')}
	onPress={importFunction}
	isLoading={isButtonLoading}
	isDisabled={isOffline}
	pressOnEnter
	success
	large
	/>
	</OfflineWithFeedback>
	</FixedFooter>

That restriction was introduced with the original category CSV flow, long before the merchant-rules import reused this component.

e407d21

d0b14ab

It is too broad for the reported case. importRules() seeds a duplicate check from the policy's locally available rules, drops the rows that already exist, and when nothing is left to create it builds the "nothing was added" confirmation locally and never calls the API.

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 225 to 234 in 4bb1d01

	// Seed the duplicate check with the policy's current rules so re-importing a spreadsheet doesn't recreate them
	const seenRuleKeys = new Set(
	Object.values(policy?.rules?.codingRules ?? {})
	.filter((rule) => rule.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && rule.filters?.right)
	.map(getRuleContentKey),
	);
	let skippedDuplicateCount = 0;
	const categoryLookup = buildImportedCategoryLookup(policyCategories);
	const invalidCategoryNames = new Set<string>();

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 289 to 298 in 4bb1d01

	setIsImportingRules(true);
	// When every row was skipped (duplicate rules and/or unknown categories), skip the API call and confirm that nothing was added
	const importFinalModal: ImportFinalModal =
	Object.keys(rules).length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)
	? {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
	promptKeyParams: {rules: 0, duplicates: skippedDuplicateCount, invalidCategories: invalidCategoryNames.size},
	}
	: await importMerchantRulesSpreadsheet(policyID, rules, invalidCategoryNames.size);

The shared component blocks the press before any of that local logic can run, so the branch that was written specifically to avoid the server is unreachable exactly when it matters. I confirmed this in the browser: with the two rules from the CSV already imported, re-importing the same file offline leaves the button at aria-disabled="true" / opacity: 0.5 and pressing it does nothing.

I also want to flag one thing about the repro steps, since it tripped me up: the Merchant header auto-maps to Updated merchant, not Merchant is. Step 4's manual remap is load-bearing — without it validate() fails first and the offline behaviour is never reached.

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

1. Add a shouldDisableImportButtonWhenOffline prop to ImportSpreadsheetColumns, defaulting to true. Every existing caller (categories, tags, multi-level tags, members, per diem, company cards, transactions) keeps today's behaviour untouched.

- isDisabled={isOffline}
+ isDisabled={isOffline && shouldDisableImportButtonWhenOffline}

2. In ImportedMerchantRulesPage, extract the rule-building/dedup/category-validation loop out of importRules() into a pure module-level buildImportedMerchantRules(spreadsheet, containsHeader, policy, policyCategories) returning {rules, skippedDuplicateCount, invalidCategoryNames}. I'd deliberately make this the single source of truth used by both the render-time gate and importRules(), rather than adding a second "can this be done locally?" predicate — otherwise the gate and the import can silently disagree about what counts as a duplicate.

3. Derive the gate from that same result, so the button only escapes the offline restriction when the press provably needs no network:

  <ImportSpreadsheetColumns
+     shouldDisableImportButtonWhenOffline={!canImportMerchantRulesOffline(builtRules)}
  />

where canImportMerchantRulesOffline is the exact condition the existing local-confirmation branch already uses:

rules.length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 334 to 342 in 4bb1d01

	<ImportSpreadsheetColumns
	spreadsheetColumns={spreadsheetColumns}
	columnNames={columnNames}
	importFunction={importRules}
	errors={isValidationEnabled ? validate() : undefined}
	columnRoles={columnRoles}
	isButtonLoading={isImportingRules}
	customHeaderText={translate('workspace.rules.merchantRules.importRulesSupportingText')}
	/>

This deliberately does not enable real merchant-rule writes offline. The moment a single row would produce a new rule, rules is non-empty, the gate returns false, and the button stays disabled — that path calls makeRequestWithSideEffects and genuinely needs an immediate server response.

One edge case worth calling out: rules the policy is currently deleting are already excluded from the duplicate seed, so a spreadsheet whose rows match only pending-delete rules correctly keeps the button disabled instead of claiming "they all already exist".

I verified this end-to-end in Chrome against a workspace with the two rules already imported — same script, same state, only the fix toggled:

• Before: offline → button aria-disabled="true", press does nothing.
• After: offline → button enabled, press shows "Import successful — No merchant rules have been added, since they all already exist." with the offline indicator still visible.

What alternative solutions did you explore?

Leaving the button enabled offline unconditionally and handling the offline case inside importRules(). I rejected it: the non-duplicate path has no optimistic/offline story, so it would either surface a confusing failure modal or silently queue a request whose result the confirmation modal is waiting on synchronously.

Tests

I'd extend tests/unit/ImportedMerchantRulesPageTest.ts, which already covers this page's pure helpers, with cases asserting that the gate opens only when every mapped row was resolved locally: all rows duplicate existing rules (open), at least one new rule (closed), policy has no rules (closed), nothing mapped so nothing was skipped (closed), and rows matching only a pending-delete rule (closed).

[lorretheboy]

Proposal

What is the root cause of that problem?

The Import button lives in the shared ImportSpreadsheetColumns component, which unconditionally disables it while offline:

App/src/components/ImportSpreadsheetColumns.tsx

Lines 123 to 131 in 4bb1d01

	<Button
	text={translate('common.import')}
	onPress={importFunction}
	isLoading={isButtonLoading}
	isDisabled={isOffline}
	pressOnEnter
	success
	large
	/>

That blanket rule exists because every spreadsheet import needs a live server response — the import command runs through API.makeRequestWithSideEffects, and offline such requests just sit in the main queue until reconnect, so the await would hang:

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

Lines 303 to 311 in 4bb1d01

	try {
	// We need the server result immediately so the initiating page can show the final confirmation modal
	// without storing transient modal state in Onyx.
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	const response = await API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.IMPORT_MERCHANT_RULES_SPREADSHEET, parameters);
	return response?.jsonCode === CONST.JSON_CODE.SUCCESS ? importFinalModal : getImportFailedFinalModal();
	} catch {
	return getImportFailedFinalModal();
	}

But PR #96522 (extending the earlier duplicate-skip work) gave the merchant-rules flow a fully client-side outcome: when every row is skipped as a duplicate and/or an unknown category, importRules builds the confirmation modal locally and never calls the API:

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 289 to 298 in 4bb1d01

	setIsImportingRules(true);
	// When every row was skipped (duplicate rules and/or unknown categories), skip the API call and confirm that nothing was added
	const importFinalModal: ImportFinalModal =
	Object.keys(rules).length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)
	? {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
	promptKeyParams: {rules: 0, duplicates: skippedDuplicateCount, invalidCategories: invalidCategoryNames.size},
	}
	: await importMerchantRulesSpreadsheet(policyID, rules, invalidCategoryNames.size);

The PR didn't touch the shared button, so the causal chain is: offline → shared component disables the button → importRules can never run → the all-skipped path that needs no network is unreachable, even though it would work perfectly offline.

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

Let the page override the offline rule instead of hard-coding it in the shared component:

1. Add an optional prop to ImportSpreadsheetColumns (e.g. isButtonDisabled?: boolean) and use it on the button as isDisabled={isButtonDisabled ?? isOffline}, so all other import pages keep today's behavior.
2. In ImportedMerchantRulesPage, extract the existing row-parsing loop in importRules (the part that produces rules, skippedDuplicateCount and invalidCategoryNames) into a helper, and also run it in a useMemo over the spreadsheet, column mapping, policy?.rules?.codingRules and policyCategories to know ahead of time whether any new rules would actually be sent to the API.
3. Pass isButtonDisabled={isOffline && hasRulesToSend}. The button then stays active offline exactly when the result is computed locally (the reported scenario — the "nothing added / categories skipped" modal shows), and remains disabled offline when a real ImportMerchantRulesSpreadsheet call would be required, preserving the reason the shared component disabled it in the first place.

The computation is pure and synchronous, so reusing it for both the press handler and the disabled state adds no duplication.

What alternative solutions did you explore? (Optional)

Always enabling the button on this page and, when pressed offline with genuinely new rules, short-circuiting before the API call with the generic failure modal. Simpler, but it shows a misleading "import failed" for an action that was never attempted, so the conditional disable above is preferable.

[samranahm]

Proposal

What is the root cause of that problem?

On the merchant rules column-mapping screen, after you upload a CSV and map the columns, the Import button is hard-disabled whenever the app is offline. So for the exact QA flow in this issue (import once online, import again with the same merchants, go offline, import a third time) the expected confirmation modal never shows. Instead the button just stays greyed out.

That button lives in the shared ImportSpreadsheetColumns component, and today it always does isDisabled={isOffline}:

App/src/components/ImportSpreadsheetColumns.tsx

Lines 123 to 131 in 4bb1d01

	<Button
	text={translate('common.import')}
	onPress={importFunction}
	isLoading={isButtonLoading}
	isDisabled={isOffline}
	pressOnEnter
	success
	large
	/>

That blanket offline guard is correct for most spreadsheet imports (categories, tags, members, per diem, company cards, wallet transactions). Those flows always await a live server response through API.makeRequestWithSideEffects, and side-effect requests are not queued offline, so pressing Import offline would just hang or fall into a failure modal.

Merchant rules are different after PR #96522. importRules in ImportedMerchantRulesPage first plans the spreadsheet against the policy's existing codingRules and categories. When every row is skipped as a duplicate and/or an unknown category, it builds the "No merchant rules have been added, since they all already exist..." modal entirely on the client and never calls the API:

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 225 to 298 in 4bb1d01

	// Seed the duplicate check with the policy's current rules so re-importing a spreadsheet doesn't recreate them
	const seenRuleKeys = new Set(
	Object.values(policy?.rules?.codingRules ?? {})
	.filter((rule) => rule.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && rule.filters?.right)
	.map(getRuleContentKey),
	);
	let skippedDuplicateCount = 0;
	const categoryLookup = buildImportedCategoryLookup(policyCategories);
	const invalidCategoryNames = new Set<string>();
	const rules: Record<string, ImportedMerchantRule> = {};
	for (let rowIndex = 0; rowIndex < rowCount; rowIndex++) {
	// "Merchant is" wins when both filter columns have a value for the same row
	const merchantIsValue = getCellValue(merchantIsColumn, rowIndex);
	const merchantToMatch = merchantIsValue || getCellValue(merchantContainsColumn, rowIndex);
	if (!merchantToMatch) {
	continue;
	}
	const updatedMerchant = getCellValue(updatedMerchantColumn, rowIndex);
	// A rule may only reference a category that exists on the workspace, so unknown cells are dropped
	// and reported in the final modal rather than stored as a category the rule could never apply
	const categoryCell = getCellValue(categoryColumn, rowIndex);
	const category = categoryCell ? (categoryLookup.get(categoryCell.toLowerCase()) ?? '') : '';
	if (categoryCell && !category) {
	invalidCategoryNames.add(categoryCell.toLowerCase());
	}
	const tag = normalizeImportedTag(getCellValue(tagColumn, rowIndex), !!policy?.hasMultipleTagLists);
	const comment = getCellValue(commentColumn, rowIndex);
	const reimbursable = parseCsvBooleanValue(getCellValue(reimbursableColumn, rowIndex));
	const billable = parseCsvBooleanValue(getCellValue(billableColumn, rowIndex));
	// Skip rows where every action cell is empty since the resulting rule would never change anything
	if (!updatedMerchant && !category && !tag && !comment && reimbursable === undefined && billable === undefined) {
	continue;
	}
	const rule: ImportedMerchantRule = {
	filters: {
	left: 'merchant',
	operator: merchantIsValue ? CONST.SEARCH.SYNTAX_OPERATORS.EQUAL_TO : CONST.SEARCH.SYNTAX_OPERATORS.CONTAINS,
	right: merchantToMatch,
	},
	...(updatedMerchant && {merchant: updatedMerchant}),
	...(category && {category}),
	...(tag && {tag}),
	...(comment && {comment: Parser.replace(comment)}),
	...(reimbursable !== undefined && {reimbursable}),
	...(billable !== undefined && {billable}),
	created: new Date().toISOString(),
	};
	const ruleKey = getRuleContentKey(rule);
	if (seenRuleKeys.has(ruleKey)) {
	skippedDuplicateCount++;
	continue;
	}
	seenRuleKeys.add(ruleKey);
	rules[rand64()] = rule;
	}
	setIsImportingRules(true);
	// When every row was skipped (duplicate rules and/or unknown categories), skip the API call and confirm that nothing was added
	const importFinalModal: ImportFinalModal =
	Object.keys(rules).length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)
	? {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
	promptKeyParams: {rules: 0, duplicates: skippedDuplicateCount, invalidCategories: invalidCategoryNames.size},
	}
	: await importMerchantRulesSpreadsheet(policyID, rules, invalidCategoryNames.size);

Only when there is at least one net-new rule does it call importMerchantRulesSpreadsheet, which really does need the network:

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

Lines 286 to 311 in 4bb1d01

	async function importMerchantRulesSpreadsheet(policyID: string, rules: Record<string, ImportedMerchantRule>, invalidCategoryCount = 0): Promise<ImportFinalModal> {
	// The API rejects an empty rules object, so fail fast when the spreadsheet produced no importable rules
	if (Object.keys(rules).length === 0) {
	return getImportFailedFinalModal();
	}
	const importFinalModal: ImportFinalModal = {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
	promptKeyParams: {rules: Object.keys(rules).length, invalidCategories: invalidCategoryCount},
	};
	const parameters: ImportMerchantRulesSpreadsheetParams = {
	policyID,
	rules: JSON.stringify(rules),
	};
	try {
	// We need the server result immediately so the initiating page can show the final confirmation modal
	// without storing transient modal state in Onyx.
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	const response = await API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.IMPORT_MERCHANT_RULES_SPREADSHEET, parameters);
	return response?.jsonCode === CONST.JSON_CODE.SUCCESS ? importFinalModal : getImportFailedFinalModal();
	} catch {
	return getImportFailedFinalModal();
	}

So the bug is a mismatch: the shared footer treats "offline" as "Import can never succeed", but for the reported re-import case the page already has a fully local success path. The offline guard blocks importRules before that path can run, which is why the duplicate/skipped-categories modal never appears offline.

Important detail from trying the naive fix: if you only comment out isDisabled={isOffline} and then try to import new rules offline, you get the generic "Import failed / Please ensure all fields are filled out correctly..." modal. That comes from the catch in importMerchantRulesSpreadsheet when the side-effect request cannot complete. So unconditionally enabling Import offline is not a good fix either.

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

Make the shared offline disable opt-in based on whether the current import actually needs the network, and have the merchant-rules page compute that from the same planning logic used on Import press.

1. In ImportSpreadsheetColumns, add an optional prop doesImportRequireNetwork (default true so every existing consumer keeps todays behavior). Change the button to:

isDisabled={isOffline && doesImportRequireNetwork}

App/src/components/ImportSpreadsheetColumns.tsx

Lines 123 to 131 in 4bb1d01

	<Button
	text={translate('common.import')}
	onPress={importFunction}
	isLoading={isButtonLoading}
	isDisabled={isOffline}
	pressOnEnter
	success
	large
	/>

2. Extract the pure spreadsheet planning helpers out of the page into a dedicated module planImportedMerchantRules.ts next to the other merchant-rules helpers (same style as getImportMerchantRulesOption.ts). That module should:

   • normalize tags / resolve categories
   • seed duplicates from existing policy codingRules (skipping pending deletes)
   • return {rules, skippedDuplicateCount, invalidCategoryCount} without assigning rand64() IDs or created timestamps during render (those stay on press only)

   This keeps the page thin and avoids stuffing a big planner into the React component file.

3. In ImportedMerchantRulesPage, call planImportedMerchantRules(...) once from the current spreadsheet mapping + policy data, then derive:

doesImportRequireNetwork = mappingIsValid && plannedImport.rules.length > 0

Pass that into ImportSpreadsheetColumns.

Meaning:

• mapping invalid: Import stays enabled offline so the user can still press and see the validation error
• all rows are duplicates / invalid categories only (rules.length === 0): Import stays enabled offline and shows the local success modal (this is the bug case)
• at least one new rule: Import stays disabled offline, becaue that path still needs makeRequestWithSideEffects

App/src/pages/workspace/rules/MerchantRules/ImportedMerchantRulesPage.tsx

Lines 199 to 305 in 4bb1d01

	const importRules = async () => {
	setIsValidationEnabled(true);
	const errors = validate();
	if (Object.keys(errors).length > 0) {
	return;
	}
	const columns = Object.values(spreadsheet?.columns ?? {});
	const merchantIsColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.MERCHANT_IS);
	const merchantContainsColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.MERCHANT_CONTAINS);
	const updatedMerchantColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.UPDATED_MERCHANT);
	const categoryColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.CATEGORY);
	const tagColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.TAG);
	const commentColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.COMMENT);
	const reimbursableColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.REIMBURSABLE);
	const billableColumn = columns.findIndex((column) => column === CONST.CSV_IMPORT_COLUMNS.BILLABLE);
	const rowCount = (spreadsheet?.data.at(0)?.length ?? 0) - (containsHeader ? 1 : 0);
	const getCellValue = (columnIndex: number, rowIndex: number): string => {
	if (columnIndex === -1) {
	return '';
	}
	const dataIndex = containsHeader ? rowIndex + 1 : rowIndex;
	return spreadsheet?.data.at(columnIndex)?.at(dataIndex)?.toString().trim() ?? '';
	};
	// Seed the duplicate check with the policy's current rules so re-importing a spreadsheet doesn't recreate them
	const seenRuleKeys = new Set(
	Object.values(policy?.rules?.codingRules ?? {})
	.filter((rule) => rule.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && rule.filters?.right)
	.map(getRuleContentKey),
	);
	let skippedDuplicateCount = 0;
	const categoryLookup = buildImportedCategoryLookup(policyCategories);
	const invalidCategoryNames = new Set<string>();
	const rules: Record<string, ImportedMerchantRule> = {};
	for (let rowIndex = 0; rowIndex < rowCount; rowIndex++) {
	// "Merchant is" wins when both filter columns have a value for the same row
	const merchantIsValue = getCellValue(merchantIsColumn, rowIndex);
	const merchantToMatch = merchantIsValue || getCellValue(merchantContainsColumn, rowIndex);
	if (!merchantToMatch) {
	continue;
	}
	const updatedMerchant = getCellValue(updatedMerchantColumn, rowIndex);
	// A rule may only reference a category that exists on the workspace, so unknown cells are dropped
	// and reported in the final modal rather than stored as a category the rule could never apply
	const categoryCell = getCellValue(categoryColumn, rowIndex);
	const category = categoryCell ? (categoryLookup.get(categoryCell.toLowerCase()) ?? '') : '';
	if (categoryCell && !category) {
	invalidCategoryNames.add(categoryCell.toLowerCase());
	}
	const tag = normalizeImportedTag(getCellValue(tagColumn, rowIndex), !!policy?.hasMultipleTagLists);
	const comment = getCellValue(commentColumn, rowIndex);
	const reimbursable = parseCsvBooleanValue(getCellValue(reimbursableColumn, rowIndex));
	const billable = parseCsvBooleanValue(getCellValue(billableColumn, rowIndex));
	// Skip rows where every action cell is empty since the resulting rule would never change anything
	if (!updatedMerchant && !category && !tag && !comment && reimbursable === undefined && billable === undefined) {
	continue;
	}
	const rule: ImportedMerchantRule = {
	filters: {
	left: 'merchant',
	operator: merchantIsValue ? CONST.SEARCH.SYNTAX_OPERATORS.EQUAL_TO : CONST.SEARCH.SYNTAX_OPERATORS.CONTAINS,
	right: merchantToMatch,
	},
	...(updatedMerchant && {merchant: updatedMerchant}),
	...(category && {category}),
	...(tag && {tag}),
	...(comment && {comment: Parser.replace(comment)}),
	...(reimbursable !== undefined && {reimbursable}),
	...(billable !== undefined && {billable}),
	created: new Date().toISOString(),
	};
	const ruleKey = getRuleContentKey(rule);
	if (seenRuleKeys.has(ruleKey)) {
	skippedDuplicateCount++;
	continue;
	}
	seenRuleKeys.add(ruleKey);
	rules[rand64()] = rule;
	}
	setIsImportingRules(true);
	// When every row was skipped (duplicate rules and/or unknown categories), skip the API call and confirm that nothing was added
	const importFinalModal: ImportFinalModal =
	Object.keys(rules).length === 0 && (skippedDuplicateCount > 0 || invalidCategoryNames.size > 0)
	? {
	titleKey: 'spreadsheet.importSuccessfulTitle',
	promptKey: 'spreadsheet.importMerchantRulesSuccessfulDescription',
	promptKeyParams: {rules: 0, duplicates: skippedDuplicateCount, invalidCategories: invalidCategoryNames.size},
	}
	: await importMerchantRulesSpreadsheet(policyID, rules, invalidCategoryNames.size);
	const didShowImportFinalModal = await showImportSpreadsheetConfirmModal(importFinalModal, {shouldHandleNavigationBack: false});
	if (!didShowImportFinalModal) {
	setIsImportingRules(false);
	return;
	}
	closeImportPageAndModal();
	};

4. On Import press, reuse that planned result: assign rule IDs + created, then either show the local zero-added modal or call importMerchantRulesSpreadsheet as today. No change needed to the API action itself for this issue.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Solution Verification Result

Kapture.2026-07-23.at.12.29.38.mp4