[$250] Personal Card - Mark transactions as reimbursable toggle is greyed out when changed 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.0-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-38986/folder/43918362/110557732/1465315656?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Honor x6b/ Chrome
App Component: User Settings

Action Performed:

Precondition: User has added a personal card that contains existing transactions

1. Navigate to Account > Wallet
2. Tap on the personal card row to view its details
3. Disconnect from the network to go offline
4. Toggle the "Mark transactions as reimbursable" switch
5. Verify the toggle changes state immediately with no greyed out styling

Expected Result:

The "Mark transactions as reimbursable" toggle changes state immediately with no greyed-out styling.

Actual Result:

Step 10. The "Mark transactions as reimbursable" toggle changes state immediately but displays greyed-out styling.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172868_1780682572008.document_4978755136387024902.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

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

[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/3baff5b4aaa9fd248b2c1a2b87d6172d0354aaa34efe40001f0051599681c73f

[godzillaxbox19982014-lgtm]

Proposal

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

w23-Personal Cards-Mark transactions as reimbursable toggle is greyed out when changed offline

What is the root cause of that problem?

I traced this to the path that handles TC:

• src/pages/Search/SearchTransactionsChangeReport.tsx:51 (useOnyx): const [personalPolicyID] = useOnyx(ONYXKEYS.PERSONAL_POLICY_ID);
• src/pages/Search/SearchTransactionsChangeReport.tsx:62 (personalDetails): const personalDetails = usePersonalDetails();
• src/pages/Search/SearchTransactionsChangeReport.tsx:99 (targetOwnerPersonalDetails): const targetOwnerPersonalDetails = useMemo(() => getPersonalDetailsForAccountID(targetOwnerAccountID, personalDetails) as PersonalDetails, [personalDetails, targetOwnerAccountID]);
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/pages/Search/SearchTransactionsChangeReport.tsx:51 and src/pages/Search/SearchTransactionsChangeReport.tsx:62 do not agree on the same TC value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/Search/SearchTransactionsChangeReport.tsx:51 to derive TC from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/Search/SearchTransactionsChangeReport.tsx:62; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: w23-Personal Cards-Mark transactions as reimbursable toggle is greyed out when changed offline.
2. Cover the counter-case near src/pages/Search/SearchTransactionsChangeReport.tsx:51 so valid existing TC behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep TC consistent at the first read/write boundary shown above.

[MelvinBot]

Proposal

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

When a user toggles "Mark transactions as reimbursable" on a personal card while offline, the row shows greyed-out (reduced-opacity) styling. The reporter expected the toggle to change instantly with no greyed-out styling.

What is the root cause of that problem?

This is the standard offline-first pending indicator, working exactly as designed — not a UI glitch.

1. setPersonalCardReimbursable optimistically writes pendingFields.reimbursable: UPDATE into Onyx (Card.ts:289-293). The clearing finallyData only runs once the request reaches the server, so while offline the pending field persists.
2. The toggle passes that pending field straight through: pendingAction={card?.pendingFields?.reimbursable} (PersonalCardDetailsHeaderMenu.tsx:84).
3. ToggleSettingOptionRow wraps the switch in OfflineWithFeedback (ToggleSettingsOptionRow.tsx:231).
4. OfflineWithFeedback applies opacity precisely when offline + a pending action exists: needsOpacity = ... (isOfflinePendingAction && !isUpdateOrDeleteError) ... (OfflineWithFeedback.tsx:98-101).

SetPersonalCardReimbursable is a server API.write command (types.ts:555) — the setting must sync to the backend. Greying it out while offline is the same feedback every other server-synced field in the app gives, and it also enables the error/red-dot feedback if the sync later fails (failureData sets errorFields.reimbursable).

So the behavior is consistent and intentional; the test case's "no greyed-out styling" expectation conflicts with the app-wide offline-first pattern. This should most likely be resolved by correcting the test expectation, not the code.

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

Recommended: Confirm with the team that the greyed-out pending state is acceptable (it matches every other offline change), and update the regression test's expected result to "toggle changes state and shows pending/greyed styling while offline until the change syncs."

Only if product explicitly wants this toggle to apply instantly with no pending styling (a deliberate UX deviation): remove the pending wiring — drop pendingFields.reimbursable from the optimistic/finally/failure data in Card.ts:283-340 and remove pendingAction/errors/onCloseError from the toggle in PersonalCardDetailsHeaderMenu.tsx:84-86. Note this trade-off: the toggle would no longer surface a sync-failure error indicator, and would diverge from the rest of the app's offline behavior.

Confidence & symptoms covered

• Root-cause mechanism: high confidence — code path traced end-to-end (action → toggle prop → OfflineWithFeedback opacity rule).
• Whether it's a bug vs. a test-expectation issue: needs product confirmation. The grey-out is the app's standard offline pattern for server-synced fields.
• Explains both reported symptoms: "changes state immediately" (optimistic Onyx merge) and "displays greyed-out styling" (offline + pending action → opacity).
• Related-issue scan found no duplicates.

---

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

[MobileMage]

Proposal

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

On the Personal Card details page (Account > Wallet > tap a personal card), toggling "Mark transactions as reimbursable" while offline immediately greys out the entire ToggleSettingOptionRow (title, subtitle, and switch) at 0.5 opacity, and the styling stays stuck until the user comes back online. The expected behavior per the QA test case is that the toggle flips instantly without any pending/greyed-out feedback, the same way other personal preference toggles behave offline.

What is the root cause of that problem?

The bug is the intersection of a Pattern B OfflineWithFeedback wrapper inside ToggleSettingOptionRow and a pendingFields.reimbursable value that the action writes optimistically but only clears via finallyData — which never fires while the request is queued offline.

The WRITE PATH is setPersonalCardReimbursable in src/libs/actions/Card.ts. The optimistic update merges pendingFields.reimbursable: UPDATE onto the card, and the clear of that field lives in finallyData, not in optimisticData:

App/src/libs/actions/Card.ts

Lines 283 to 339 in 380da60

	function setPersonalCardReimbursable(cardID: number, reimbursable: boolean, previousValue?: boolean) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.CARD_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CARD_LIST,
	value: {
	[cardID]: {
	reimbursable,
	pendingFields: {
	reimbursable: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	errorFields: {
	reimbursable: null,
	},
	},
	},
	},
	];
	const finallyData: Array<OnyxUpdate<typeof ONYXKEYS.CARD_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CARD_LIST,
	value: {
	[cardID]: {
	pendingFields: {
	reimbursable: null,
	},
	},
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.CARD_LIST>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CARD_LIST,
	value: {
	[cardID]: {
	...(previousValue === undefined ? {} : {reimbursable: previousValue}),
	pendingFields: {
	reimbursable: null,
	},
	errorFields: {
	reimbursable: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	},
	},
	},
	},
	];
	const parameters: SetPersonalCardReimbursableParams = {
	cardID,
	reimbursable,
	};
	API.write(WRITE_COMMANDS.SET_PERSONAL_CARD_REIMBURSABLE, parameters, {optimisticData, finallyData, failureData});

SaveResponseInOnyx only applies successData / failureData / finallyData after the request resolves, so while the user is offline the request sits in the SequentialQueue and pendingFields.reimbursable stays set to UPDATE.

The READ PATH is PersonalCardDetailsHeaderMenu which forwards that value to ToggleSettingOptionRow via pendingAction={card?.pendingFields?.reimbursable}:

App/src/pages/settings/Wallet/PersonalCardDetailsHeaderMenu.tsx

Lines 77 to 88 in 380da60

	<ToggleSettingOptionRow
	title={translate('cardPage.markTransactionsAsReimbursable')}
	subtitle={translate('cardPage.markTransactionsDescription')}
	shouldPlaceSubtitleBelowSwitch
	switchAccessibilityLabel={translate('cardPage.markTransactionsAsReimbursable')}
	isActive={reimbursableSetting}
	onToggle={(isOn) => card && setPersonalCardReimbursable(card.cardID, isOn, reimbursableSetting)}
	pendingAction={card?.pendingFields?.reimbursable}
	errors={card?.errorFields?.reimbursable ?? undefined}
	onCloseError={() => card && clearCardErrorField(card.cardID, 'reimbursable')}
	wrapperStyle={[styles.ph5, styles.mb3]}
	/>

Inside ToggleSettingOptionRow, the row is wrapped in OfflineWithFeedback, which computes needsOpacity whenever the user is offline AND a pendingAction exists:

const isOfflinePendingAction = !!isOffline && !!pendingAction;
const needsOpacity = (!shouldDisableOpacity && ((isOfflinePendingAction && !isUpdateOrDeleteError) || isAddError)) || shouldForceOpacity;

needsOpacity === true swaps the container style to styles.offlineFeedbackPending (the 0.5-opacity greyed-out style). Because finallyData cannot run offline, this condition is true for the full duration of the offline session — the toggle flips its visual isOn state instantly, but the whole row is stuck at 0.5 opacity, exactly matching the screenshot in the report. This is essentially Pattern B applied to a setting where QA expects Pattern A (Optimistic without feedback).

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

Convert this toggle from Pattern B to Pattern A — the API call is a simple boolean preference update where the server response can be anticipated and the user does not need offline feedback that the request is queued (matching the "pin chat" example in contributingGuides/philosophies/OFFLINE.md). The fix has two coordinated parts: stop writing the pending field in the action, and stop forwarding it to the toggle.

In src/libs/actions/Card.ts, drop the pendingFields.reimbursable write from optimisticData and the corresponding clear from finallyData (the failureData revert of the value plus errorFields for true API failures still works correctly):

// optimisticData becomes just the value flip + clearing any stale error
value: {[cardID]: {reimbursable, errorFields: {reimbursable: null}}}

In src/pages/settings/Wallet/PersonalCardDetailsHeaderMenu.tsx, remove the pendingAction={card?.pendingFields?.reimbursable} prop from the ToggleSettingOptionRow so OfflineWithFeedback inside it sees no pendingAction and renders styles.offlineFeedbackDefault (no opacity). Keep errors and onCloseError so a genuine API failure still surfaces the red-dot error row and lets the user dismiss it. This is the same shape used by other preference-style toggles where offline feedback is intentionally suppressed, and it doesn't affect any other caller because pendingFields.reimbursable and setPersonalCardReimbursable are only consumed by this one page.

What alternative solutions did you explore? (Optional)

We considered moving the pendingFields.reimbursable: null clear from finallyData into optimisticData so the field is cleared synchronously — that would also stop the grey styling, but it leaves the now-meaningless pendingFields.reimbursable: UPDATE write that flips on for one render and could briefly grey the row on first paint. Dropping the pending field outright is cleaner and matches Pattern A guidance for boolean preference toggles whose server response we can anticipate.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[melvin-bot]

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