[$250] Tax rate deleted offline is not displayed in workspace default settings page

[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.26-5
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/13176868/test-cases/41237329
Email or phone of affected tester (no customers): htad26+uietyiuy@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10 / Chrome, iOS 26.5 / iPhone 13
App Component: Workspace Settings

Action Performed:

Precondition
Taxes are enabled in a workspace

1. As an admin, navigate to the Taxes page of the workspace settings
2. Go offline
3. Click on a tax rate > delete it
4. Go to Settings > Workspace currency default

Expected Result:

Deleted tax rate can't be selected and is styled correctly with strike-through

Actual Result:

The deleted tax rate is not displayed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7197879_1783018111293.bandicam_2026-07-02_21-43-28-089.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7197879

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072763386227052876
• Upwork Job ID: 2072763386227052876
• Last Price Increase: 2026-07-16

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Workspace currency default" (and "Foreign currency default") tax pages render their list through the shared TaxPicker, which builds options via getTaxRatesSection(). That util filters out every tax rate flagged isDisabled:

• src/libs/TaxOptionsListUtils.ts:73 — const enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled);

When you delete a tax rate offline, the optimistic update sets both pendingAction: DELETE and isDisabled: true:

• src/libs/actions/TaxRate.ts:341

So the pending-deleted rate is dropped from every section and disappears entirely, instead of showing struck-through and non-selectable. By contrast, the main taxes list (WorkspaceTaxesPage.tsx:172) iterates over all taxes without an isDisabled filter, which is why it correctly renders the strike-through there.

Supporting evidence

• The downstream option mapper already handles this case — getTaxRatesOptions sets isDisabled: !!isDisabled || pendingAction === DELETE and passes pendingAction through — but it's never reached for these rates because they're filtered out at line 73 first.
• Both settings pages delegate entirely to TaxPicker with no per-page filtering, and pass no transactionID/transaction (WorkspaceTaxesSettingsWorkspaceCurrency.tsx:60-66, same in WorkspaceTaxesSettingsForeignCurrency.tsx).
• TaxPicker's existing deletedTaxOption re-add logic (TaxPicker.tsx:95-105) only fires for a deleted rate that is the current transaction's selected taxCode; with no transaction on these pages, it never applies.

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

Stop filtering out pending-deleted rates in getTaxRatesSection — keep rates whose pendingAction === DELETE so they render disabled + struck-through (the existing getTaxRatesOptions handling already covers rendering), while still excluding admin-disabled rates. In practice, adjust the enabledTaxRates filter at TaxOptionsListUtils.ts:73 to also keep rates with a pending DELETE action.

The implementer should verify SingleSelectListItem renders the pending/strike-through state and that keeping these rates doesn't regress the expense/IOU TaxPicker flows (which share this util). If a narrower blast radius is preferred, gate the behavior behind an opt-in flag on getTaxRatesSection passed only from the workspace-default path.

What alternative solutions did you explore? (Optional)

Adding an opt-in flag (e.g. includePendingDeleteTaxRates) to getTaxRatesSection so only the workspace-default pages show pending-deleted rates, leaving the expense-picker flows unchanged.

---

Note: This looks like a duplicate of #95231 (same title, already priced) — worth confirming before opening new work here.

---

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

[kitvasyl]

Proposal

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

A tax rate deleted while offline disappears from the Workspace currency default picker instead of remaining visible, disabled, and struck through while the deletion is pending.

What is the root cause of that problem?

src/pages/workspace/taxes/WorkspaceTaxesSettingsWorkspaceCurrency.tsx renders the shared TaxPicker, whose TaxPicker function builds its sections through getTaxRatesSection. That path omits policy tax rates with a pending delete. Its special deletedTaxOption handling only applies to transaction taxes, so it is not activated on this settings screen because there is no transaction or taxCode.

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

Add an explicit prop to TaxPicker for retaining pending-deletion policy rates. When enabled, include those rates in the generated sections with isDisabled: true and their delete pendingAction, allowing SingleSelectListItem to render the existing strike-through treatment and prevent selection. Enable this prop from WorkspaceTaxesSettingsWorkspaceCurrency.tsx.

Add a focused test confirming that an offline-deleted tax remains listed, struck through, and non-selectable in the workspace currency default picker.

What alternative solutions did you explore? (Optional)

Changing the transaction-specific deletedTaxOption branch was considered, but that branch depends on transaction fields and would mix transaction recovery behavior with workspace-settings optimistic state.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

When a tax rate is deleted offline, deletePolicyTaxes() keeps it in policy.taxRates.taxes but marks it with pendingAction: DELETE and isDisabled: true until the queued request succeeds

App/src/libs/actions/TaxRate.ts

Lines 331 to 343 in 6d53532

	},
	};
	}
	const onyxData: OnyxData<typeof ONYXKEYS.COLLECTION.POLICY> = {
	optimisticData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policy.id}`,
	value: {
	taxRates: {
	pendingFields: {foreignTaxDefault: isForeignTaxRemoved ? CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE : null},
	foreignTaxDefault: isForeignTaxRemoved ? firstTaxID : foreignTaxDefault,

The workspace currency default picker then builds its list through TaxPicker using only the selected tax display name from the workspace default page

App/src/pages/workspace/taxes/WorkspaceTaxesSettingsWorkspaceCurrency.tsx

Lines 33 to 66 in 6d53532

	},
	policy,
	}: WorkspaceTaxesSettingsWorkspaceCurrencyProps) {
	const {translate} = useLocalize();
	const styles = useThemeStyles();
	const defaultExternalID = policy?.taxRates?.defaultExternalID;
	const selectedTaxRate = defaultExternalID && getWorkspaceTaxesSettingsName(policy, defaultExternalID);
	const submit = (taxes: TaxRatesOption) => {
	setWorkspaceCurrencyDefault(policyID, taxes.code ?? '', defaultExternalID);
	Navigation.goBack(ROUTES.WORKSPACE_TAXES_SETTINGS.getRoute(policyID));
	};
	const dismiss = () => {
	Navigation.goBack(ROUTES.WORKSPACE_TAXES_SETTINGS.getRoute(policyID));
	};
	return (
	<AccessOrNotFoundWrapper
	accessVariants={[CONST.POLICY.ACCESS_VARIANTS.ADMIN, CONST.POLICY.ACCESS_VARIANTS.PAID]}
	policyID={policyID}
	featureName={CONST.POLICY.MORE_FEATURES.ARE_TAXES_ENABLED}
	>
	<ScreenWrapper
	enableEdgeToEdgeBottomSafeAreaPadding
	shouldEnableMaxHeight
	testID="WorkspaceTaxesSettingsWorkspaceCurrency"
	style={styles.defaultModalContainer}
	>
	<HeaderWithBackButton title={translate('workspace.taxes.workspaceDefault')} />
	<View style={[styles.mb4, styles.flex1]}>
	<TaxPicker

and getTaxRatesSection() filters the transformed tax list down to !taxRate.isDisabled before building the visible options

App/src/libs/TaxOptionsListUtils.ts

Lines 69 to 77 in 6d53532

	}): Array<Section<TaxRatesOption>> {
	const policyRatesSections = [];
	const taxes = transformedTaxRates(policy, transaction);
	const sortedTaxRates = sortTaxRates(taxes, localeCompare);
	const selectedOptionNames = new Set(selectedOptions.map((selectedOption) => selectedOption.modifiedName));
	const enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled);
	const enabledTaxRatesNames = new Set(enabledTaxRates.map((tax) => tax.modifiedName));

Because the offline-deleted tax is now disabled and is not necessarily the currently selected default, it is removed from the picker data before getTaxRatesOptions() can apply the existing pending-delete disabled/feedback state

App/src/libs/TaxOptionsListUtils.ts

Lines 38 to 48 in 6d53532

	/**
	* Builds the options for taxRates
	*/
	function getTaxRatesOptions(taxRates: Array<Partial<TaxRate>>): TaxRatesOption[] {
	return taxRates.map(({code, modifiedName, isDisabled, isSelected, pendingAction}, index) => ({
	code,
	text: modifiedName,
	keyForList: `${modifiedName}-${index}`,
	searchText: modifiedName,
	tooltipText: modifiedName,
	isDisabled: !!isDisabled || pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,

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

Update getTaxRatesSection() so pending-delete tax rates remain visible in the picker even when isDisabled is true. The list should continue excluding normally disabled tax rates from selectable options, but it should include rates where pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE in the visible tax-rate collection. getTaxRatesOptions() already marks pending-delete rows as disabled and passes pendingAction through, and BaseSelectListItem forwards that pending action to the offline feedback wrapper for strike-through styling

App/src/components/SelectionList/ListItem/BaseSelectListItem.tsx

Lines 52 to 60 in 6d53532

	wrapperStyle={[styles.flex1, styles.justifyContentBetween, styles.sidebarLinkInner, styles.userSelectNone, styles.optionRow, wrapperStyle]}
	isFocused={isFocused}
	isFocusVisible={isFocusVisible}
	isDisabled={isDisabled}
	showTooltip={showTooltip}
	onSelectRow={onSelectRow}
	onDismissError={onDismissError}
	shouldPreventEnterKeySubmit={shouldPreventEnterKeySubmit}
	rightHandSideComponent={rightHandSideComponent}

Concretely, split the current enabledTaxRates logic into a selectable/enabled set and a visible set that includes pending-delete rates. Use the visible set for the rendered/searchable options and selected-option de-duplication, while keeping pending-delete rows disabled so they cannot be selected. This keeps the offline-deleted tax visible with strike-through in both workspace currency default and foreign currency default pickers, which share the same TaxPicker path

App/src/pages/workspace/taxes/WorkspaceTaxesSettingsForeignCurrency.tsx

Lines 32 to 66 in 6d53532

	},
	policy,
	}: WorkspaceTaxesSettingsForeignCurrencyProps) {
	const {translate} = useLocalize();
	const styles = useThemeStyles();
	const foreignTaxDefault = policy?.taxRates?.foreignTaxDefault ?? '';
	const selectedTaxRate = getWorkspaceTaxesSettingsName(policy, foreignTaxDefault);
	const submit = (taxes: TaxRatesOption) => {
	setForeignCurrencyDefault(policyID, taxes.code ?? '', foreignTaxDefault);
	Navigation.goBack(ROUTES.WORKSPACE_TAXES_SETTINGS.getRoute(policyID));
	};
	const dismiss = () => {
	Navigation.goBack(ROUTES.WORKSPACE_TAXES_SETTINGS.getRoute(policyID));
	};
	return (
	<AccessOrNotFoundWrapper
	accessVariants={[CONST.POLICY.ACCESS_VARIANTS.ADMIN, CONST.POLICY.ACCESS_VARIANTS.PAID]}
	policyID={policyID}
	featureName={CONST.POLICY.MORE_FEATURES.ARE_TAXES_ENABLED}
	>
	<ScreenWrapper
	enableEdgeToEdgeBottomSafeAreaPadding
	shouldEnableMaxHeight
	testID="WorkspaceTaxesSettingsForeignCurrency"
	style={styles.defaultModalContainer}
	>
	<HeaderWithBackButton title={translate('workspace.taxes.foreignDefault')} />
	<View style={[styles.mb4, styles.flex1]}>
	<TaxPicker

Also update the existing TaxOptionsListUtils unit coverage so the pending-delete tax fixture includes isDisabled: true, matching the optimistic state created by deletePolicyTaxes().

What alternative solutions did you explore? (Optional)

I considered patching only WorkspaceTaxesSettingsWorkspaceCurrency to pass the deleted tax as a selected option, but that would only help when the deleted tax is the current default and would leave the shared tax picker list behavior wrong for the foreign default picker and any other tax picker using getTaxRatesSection().

[shivang-goliyan]

Proposal

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

When you delete a tax rate while offline and then open the workspace currency default (or foreign currency default) picker, the deleted rate is completely missing from the list. What should happen is the rate stays visible but unselectable with a strike-through, the same way a pending offline delete looks everywhere else in the app.

What is the root cause of that problem?

The picker list is built by getTaxRatesSection() in src/libs/TaxOptionsListUtils.ts. At line 73 it filters the rates down to only enabled ones before doing anything else:

const enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled);

The problem is what an offline delete writes to Onyx. In deletePolicyTaxes() (src/libs/actions/TaxRate.ts, the optimistic update around line 341), a pending-delete tax gets both flags set:

acc[taxID] = {pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE, errors: null, isDisabled: true};

So a tax that's pending delete also carries isDisabled: true. The line-73 filter sees that flag and drops the rate entirely, before getTaxRatesOptions() ever runs. That's the piece that would have marked the row disabled and passed its pendingAction down to OfflineWithFeedback for the strike-through. No row reaches the list, so there's nothing to strike through.

I confirmed the rest of the pipeline is fine. getTaxRatesOptions (line 45) already sets isDisabled from the pending action and forwards pendingAction, and TaxPicker → SingleSelectListItem → BaseListItem wraps it in <OfflineWithFeedback pendingAction={...}>. The only break is that one filter.

One thing that hid this: the existing test tests/unit/TaxOptionsListUtilsTest.ts seeds a deleted rate with pendingAction: 'delete' but no isDisabled, and asserts the row shows. It's green because it doesn't replicate what production actually writes. Real deletePolicyTaxes adds isDisabled: true, which is exactly what makes the row vanish.

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

Keep pending-delete rates in the list at the filter. In src/libs/TaxOptionsListUtils.ts line 73:

const enabledTaxRates = sortedTaxRates.filter(
    (taxRate) => !taxRate.isDisabled || taxRate.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
);

This is display-layer only. A rate that's genuinely toggled off stays hidden. A rate that's pending delete now survives the filter, and getTaxRatesOptions already renders it as unselectable (isDisabled: true) with the strike-through via pendingAction. No change to the delete action itself, so there's no risk to the distance-rate behavior that flag was added for.

I'd also update the getTaxRatesSection case in tests/unit/TaxOptionsListUtilsTest.ts so the deleted rate carries both isDisabled: true and pendingAction: 'delete', matching what production writes, and assert the row still appears. That case fails today and passes after this change.

Worth noting for whoever picks this up: there's a narrower separate gap where, if the deleted tax is the currently selected default, it flows through selectedOptions as a plain Tax with no pendingAction, so a selected-and-deleted default could show without a strike-through. The reported repro (deleting a non-default rate) is fully fixed by the line-73 change; I'm flagging the selected-default case as a smaller follow-up rather than folding an unrelated path into this fix.

What alternative solutions did you explore? (Optional)

Revert the optimistic delete in TaxRate.ts to stop setting isDisabled: true. That matches the existing test and the pre-regression shape, but the flag was added deliberately in fd3dac2 to fix "Distance rates - Enabled distance rate changes to Disabled after deleting it", and it mirrors how Category and Tag deletes behave. Removing it risks bringing that bug back and makes a pending-delete tax look enabled to other isDisabled-based logic. The filter change is more surgical and keeps the fix on the display side where the bug actually is.

[lorretheboy]

Proposal

What is the root cause of that problem?

When a tax rate is deleted offline, the optimistic data marks it with both pendingAction: 'delete' and isDisabled: true:

App/src/libs/actions/TaxRate.ts

Lines 340 to 343 in a11a9c8

	taxes: taxesToDelete.reduce<TaxRateDeleteMap>((acc, taxID) => {
	acc[taxID] = {pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE, errors: null, isDisabled: true};
	return acc;
	}, {}),

TaxPicker (used by the workspace-default currency page) builds its list via the shared getTaxRatesSection, which filters out every disabled tax rate before building options:

App/src/libs/TaxOptionsListUtils.ts

Line 73 in a11a9c8

const enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled);

So the offline-deleted rate is dropped from the list entirely (unless it happens to be the currently selected default) instead of being shown greyed-out with strike-through. The display machinery for that already exists — getTaxRatesOptions disables the row and passes pendingAction through, which BaseListItem feeds to OfflineWithFeedback for the strike-through — the item just never reaches it because of the filter above:

App/src/libs/TaxOptionsListUtils.ts

Lines 38 to 49 in a11a9c8

	function getTaxRatesOptions(taxRates: Array<Partial<TaxRate>>): TaxRatesOption[] {
	return taxRates.map(({code, modifiedName, isDisabled, isSelected, pendingAction}, index) => ({
	code,
	text: modifiedName,
	keyForList: `${modifiedName}-${index}`,
	searchText: modifiedName,
	tooltipText: modifiedName,
	isDisabled: !!isDisabled || pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	isSelected,
	pendingAction,
	}));
	}

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

In getTaxRatesSection, keep rates that are pending deletion when building enabledTaxRates, so a rate disabled only because of an offline delete stays visible:

const enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled || taxRate.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);

getTaxRatesOptions then already renders it as non-selectable (isDisabled: !!isDisabled || pendingAction === DELETE) and with strike-through (via the pendingAction passed down to OfflineWithFeedback), matching the expected result. Once the request succeeds, the success data removes the rate from Onyx and it disappears from the list.

Because the fix is in the shared section builder, it also fixes the same offline-delete gap in every other TaxPicker consumer (foreign currency default page, expense tax rate page, distance rate tax edit page).

What alternative solutions did you explore? (Optional)

Stop setting isDisabled: true in the optimistic data of deletePolicyTaxes and rely on pendingAction alone — rejected because other logic (e.g. getEnabledTaxRateCount, default-tax fallbacks) intentionally treats the rate as unavailable while the delete is pending.

[oqildev]

Proposal

What is the root cause of that problem?

Two different code paths build the "tax rates" list, and only the Taxes list page is offline-aware.

When you delete a rate offline, deletePolicyTaxes optimistically writes {pendingAction: DELETE, errors: null, isDisabled: true} onto that rate — note it sets isDisabled: true, not just the pending action:

App/src/libs/actions/TaxRate.ts

Lines 340 to 343 in a11a9c8

	taxes: taxesToDelete.reduce<TaxRateDeleteMap>((acc, taxID) => {
	acc[taxID] = {pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE, errors: null, isDisabled: true};
	return acc;
	}, {}),

The Taxes list page keeps that rate visible while offline (its taxRows only drops a deleting rate when !isOffline), which is why it correctly shows struck-through there:

App/src/pages/workspace/taxes/WorkspaceTaxesPage.tsx

Lines 172 to 177 in a11a9c8

	return Object.entries(policy.taxRates?.taxes ?? {}).reduce<WorkspaceTaxTableRowData[]>((acc, [key, value]) => {
	const isDeleting = value.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
	if (!isOffline && isDeleting) {
	return acc;
	}

The "Workspace currency default" page renders a TaxPicker instead, whose rows come from getTaxRatesSection:

App/src/pages/workspace/taxes/WorkspaceTaxesSettingsWorkspaceCurrency.tsx

Lines 59 to 67 in a11a9c8

	<View style={[styles.mb4, styles.flex1]}>
	<TaxPicker
	selectedTaxRate={selectedTaxRate}
	policyID={policyID}
	onSubmit={submit}
	onDismiss={dismiss}
	addBottomSafeAreaPadding
	/>
	</View>

App/src/components/TaxPicker.tsx

Lines 117 to 123 in a11a9c8

	const sections = getTaxRatesSection({
	policy,
	searchValue,
	localeCompare,
	selectedOptions,
	transaction: currentTransaction,
	});

getTaxRatesSection filters the list down to enabledTaxRates with sortedTaxRates.filter((taxRate) => !taxRate.isDisabled):

App/src/libs/TaxOptionsListUtils.ts

Lines 69 to 77 in a11a9c8

	const taxes = transformedTaxRates(policy, transaction);
	const sortedTaxRates = sortTaxRates(taxes, localeCompare);
	const selectedOptionNames = new Set(selectedOptions.map((selectedOption) => selectedOption.modifiedName));
	const enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled);
	const enabledTaxRatesNames = new Set(enabledTaxRates.map((tax) => tax.modifiedName));
	const enabledTaxRatesWithoutSelectedOptions = enabledTaxRates.filter((tax) => tax.modifiedName && !selectedOptionNames.has(tax.modifiedName));
	const selectedTaxRateWithDisabledState: Tax[] = [];
	const numberOfTaxRates = enabledTaxRates.length;

Because the offline-deleted rate now carries isDisabled: true, line 73 drops it entirely. It never reaches getTaxRatesOptions, whose line 45 (isDisabled: !!isDisabled || pendingAction === DELETE) and pendingAction passthrough would have rendered it disabled with the strike-through:

App/src/libs/TaxOptionsListUtils.ts

Lines 38 to 49 in a11a9c8

	function getTaxRatesOptions(taxRates: Array<Partial<TaxRate>>): TaxRatesOption[] {
	return taxRates.map(({code, modifiedName, isDisabled, isSelected, pendingAction}, index) => ({
	code,
	text: modifiedName,
	keyForList: `${modifiedName}-${index}`,
	searchText: modifiedName,
	tooltipText: modifiedName,
	isDisabled: !!isDisabled || pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	isSelected,
	pendingAction,
	}));
	}

So the strike-through plumbing already exists; the rate is filtered out before it can be used. There's no isOffline branch here equivalent to WorkspaceTaxesPage line 175, which is the real gap.

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

Make getTaxRatesSection (the shared selector both currency-default pages read through TaxPicker) offline-aware, mirroring WorkspaceTaxesPage.taxRows.

In the enabledTaxRates filter at TaxOptionsListUtils.ts#L73, stop dropping a rate whose pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE when getIsOffline() is true — keep it in the list. It already flows through getTaxRatesOptions, which will mark it isDisabled: true and carry its pendingAction (line 45/47), so the list item renders it struck-through via OfflineWithFeedback and it can't be selected. Key the exception on pendingAction === DELETE specifically, not on "offline + disabled", so genuinely disabled rates (toggled off, pendingAction: UPDATE) stay hidden as they do today.

This is a selector/util fix, not a per-page one, because both the workspace-default and foreign-default flows resolve their options from getTaxRatesSection.

Edge cases the fix touches: offline optimistic delete (rate shown disabled + strike-through, unselectable); reconnect/success (deletePolicyTaxes successData sets the tax to null, so the row disappears — no change needed); failure rollback (failureData clears pendingAction and restores isDisabled to the original, so the rate reverts to a normal selectable option). Manually disabled rates remain excluded.

What alternative solutions did you explore? (Optional)

Patch this only inside TaxPicker by re-appending offline pending-delete rates to the sections, the way the component already re-appends deletedTaxOption via updatedSections (TaxPicker.tsx#L155-L160). Rejected: that duplicates the offline rule in a component while the real filter lives in the shared getTaxRatesSection, so the foreign-default flow and any other consumer of that util would each need the same patch and could drift out of sync.

Another option is to stop setting isDisabled: true in deletePolicyTaxes optimistic data (TaxRate.ts#L341). Rejected: that flag is deliberate so the rate reads as unusable everywhere while the delete is pending, and removing it would let the rate stay selectable in other tax pickers offline — a worse regression than the display bug.

[aswin-s]

Note: This proposal is not a duplicate. It changes a different location in the code to address the issue.

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

When an admin deletes a tax rate while offline and then opens Settings > Workspace currency default, the tax rate that was just deleted disappears from the TaxPicker list on Web/iOS/Android. Expected behavior: because the DELETE is still pending (offline), the row should render with a strike-through and be non-selectable, matching how other offline-pending deletions are shown across the app.

What is the root cause of that problem?

deletePolicyTaxes optimistically writes pendingAction: DELETE and isDisabled: true onto each deleted tax entry in policy.taxRates.taxes (per S1 findings on Policy.ts). transformedTaxRates in src/libs/TransactionUtils/index.ts:2252 passes those entries through unchanged (keeping isDisabled/pendingAction), and then getTaxRatesSection in src/libs/TaxOptionsListUtils.ts:73 computes enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled) — which drops the offline-deleted tax entirely because the optimistic write sets isDisabled: true. Every downstream section (enabledTaxRatesWithoutSelectedOptions, the search branch, and the two "All" branches at lines 120/139) is built from that filtered list, so the pending-delete row is never handed to getTaxRatesOptions and cannot render its strike-through / disabled state.

Notably, getTaxRatesOptions (lines 38–49 of TaxOptionsListUtils.ts) already does the right thing for any entry that reaches it: it destructures pendingAction, propagates it onto the returned TaxRatesOption, and marks isDisabled: true when pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE. The gap is purely at the filter one step earlier — the pending-delete row is silently discarded before getTaxRatesOptions ever sees it.

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

1. src/libs/TaxOptionsListUtils.ts — fix the enabledTaxRates filter (line 73). Change the filter so that a tax rate is kept when it carries a pending DELETE action, even though isDisabled is true on the optimistic write:

// Before
const enabledTaxRates = sortedTaxRates.filter((taxRate) => !taxRate.isDisabled);

// After
const enabledTaxRates = sortedTaxRates.filter(
    (taxRate) => !taxRate.isDisabled || taxRate.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
);

This ensures offline-deleted tax entries flow through to getTaxRatesOptions, which already propagates pendingAction onto the returned option and re-asserts isDisabled: true for DELETE entries — so the row appears in the list but remains non-selectable.

2. src/components/TaxPicker.tsx — no change required. SelectionListWithSections respects the isDisabled flag from the option object returned by getTaxRatesOptions, and pendingAction is already threaded through so OfflineWithFeedback / strike-through styling is applied by the row renderer. Once the filter fix in step 1 lets the pending-delete row reach getTaxRatesOptions, the display and non-selectability work correctly without any changes to TaxPicker.

3. Verify on iOS, Android, and Web/Chrome per the issue's reproduction steps: delete a tax rate while offline, then navigate to Settings > Workspace currency default — the deleted rate should appear with strike-through and be non-selectable. No server-side change is required because the optimistic Onyx write already carries pendingAction: DELETE.

What alternative solutions did you explore? (Optional)

Filtering enabledTaxRates on !isDisabled && pendingAction !== DELETE alone would re-include the row, but this is logically equivalent to the fix above — the key point is that pending-delete rows must reach getTaxRatesOptions rather than being discarded, since that helper already contains all the logic needed to render them correctly as disabled/pending entries.

[abbasifaizan70]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.