[$250] Email- Click 'Reveal' leads to Add personal info and Email is incorrect content

[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: 9.4.41-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: #96224
Email or phone of affected tester (no customers): duytestnguyen+273@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 Home/Chrome
App Component: User Settings

Action Performed:

Preconditions:

• Create a new account, validate email
• Create a workspace, add Expensify card and assign to yourself

1. Open https://staging.new.expensify.com/
2. Go to Accounts > Wallet
3. Click on Expensify card
4. Click on 'Reveal' button
5. Fill in the form and complete the flow
6. When Magic code prompt openned, Open the sent email

Expected Result:

At step 4, the Magic code prompt is displayed
At step 6, Verify the email reads "...trying to: • Reveal details for your Expensify card ending in NNNN", where NNNN matches the last four of the card.

Actual Result:

At step 4, the Add personal info form is displayed
At step 6, the email content is: "Log in to your account or access a secure feature."

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213229_1784618882207.bandicam_2026-07-21_14-04-21-343.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022079493015347247867
• Upwork Job ID: 2079493015347247867
• Last Price Increase: 2026-07-21

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The preconditions create a brand-new account and then reveal an Expensify card. A new account hasn't filled in personal details yet, so the Reveal button takes a different code path than the one #96224 migrated.

In the Reveal onPress, when address/personal details are missing the app routes into the Missing personal details flow instead of the normal card-reveal magic-code page (ExpensifyCardPage/index.tsx:531-532):

• Symptom 1 (“Add personal info” instead of magic code): this is that gate firing — a card can’t be revealed without personal details, so the form is shown first. That part is working as designed; the QA account simply wasn't fully set up.
• Symptom 2 (generic email): the missing-details flow ends at MissingPersonalDetailsMagicCodePage, whose sendValidateCode calls requestValidateCodeAction() with no reasonCode (MissingPersonalDetailsMagicCodePage.tsx:111). With no reason, the backend uses the generic fallback copy (“…log in to your account or access a secure feature.”).

For comparison, the migrated page passes the reason correctly (ExpensifyCardVerifyAccountPage.tsx:72). PR #96224 explicitly listed MissingPersonalDetailsMagicCodePage under the “none — generic fallback” callers and deferred it to a follow-up — so this is a known coverage gap, not a broken migration. It just happens to be exactly the path a fresh QA account hits.

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

In MissingPersonalDetailsMagicCodePage.tsx, when the flow is revealing a virtual card (isVirtualCard is true and a cardID is present), pass the same reason the migrated page uses:

• reasonCode: REVEAL_CARD_DETAILS and reasonCardID: Number(cardID) (via COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS).
• For the non-reveal case (physical-card shipping, which shares this page), keep the current no-arg requestValidateCodeAction() call.

isVirtualCard and cardID are already available in this component, so no new plumbing is needed. This is entirely within Expensify/App.

Supporting evidence & edge cases

• This page is dual-purpose: isVirtualCard → reveal-details (setPersonalDetailsAndRevealExpensifyCard); otherwise → physical-card shipping (updatePersonalDetailsAndShipExpensifyCards). Only the reveal branch should carry reveal_card_details.
• Reproduces on any account missing personal details; an account that has already completed personal details skips the gate and gets the correct email via ExpensifyCardVerifyAccountPage.
• Symptom 1 is expected product behavior (personal details are required before reveal), so no change is needed there — the report is really about the email copy.
• No related open/closed issues found for this in Expensify/App.

What alternative solutions did you explore? (Optional)

None — the fix mirrors the existing migrated call site.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96604) 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 a user with no personal details on file clicks "Reveal" on their Expensify Card, they are correctly routed to the "Add personal info" flow (since the reveal action requires legal name/DOB/phone/address on file). After they fill in the form and the magic-code prompt appears, the magic-code email that is sent does not describe the reveal action — it contains the generic text "Log in to your account or access a secure feature." instead of the expected "...trying to: • Reveal details for your Expensify card ending in NNNN".

What is the root cause of that problem?

Every other place in the app that requests a magic code for a specific security-sensitive action passes a reasonCode (and, for card reveals, a reasonCardID) to requestValidateCodeAction, which the backend uses to render the action-specific email copy. For example, the "direct" reveal flow (used when personal details are already on file) does this correctly:

App/src/pages/settings/Wallet/ExpensifyCardPage/ExpensifyCardVerifyAccountPage.tsx

Lines 69 to 81 in 007bd53

	<ValidateCodeActionContent
	title={translate('cardPage.validateCardTitle')}
	descriptionPrimary={translate('cardPage.enterMagicCode', primaryLogin)}
	sendValidateCode={() => requestValidateCodeAction({reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number.parseInt(cardID, 10)})}
	validateCodeActionErrorField="revealExpensifyCardDetails"
	handleSubmitForm={handleRevealCardDetails}
	validateError={validateError}
	clearError={() => setValidateError({})}
	onClose={() => {
	navigateBack();
	}}
	isLoading={privatePersonalDetails?.isLoading}
	/>

The same pattern is used for Travel CVV reveal, contact-method verification, sign-in, etc. However, when the reveal is initiated through the "Add personal info" flow (i.e. areAddressAndPersonalDetailsMissing sent the user to MISSING_PERSONAL_DETAILS first), the magic-code page for that flow calls requestValidateCodeAction() with no arguments at all:

App/src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx

Lines 107 to 121 in 007bd53

	return (
	<ValidateCodeActionContent
	title={translate('cardPage.validateCardTitle')}
	descriptionPrimary={translate('cardPage.enterMagicCode', primaryLogin ?? '')}
	sendValidateCode={() => requestValidateCodeAction()}
	validateCodeActionErrorField="personalDetails"
	handleSubmitForm={handleSubmitForm}
	validateError={!isEmptyObject(revealCardError) ? revealCardError : validateLoginError}
	clearError={clearError}
	onClose={() => {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.MISSING_PERSONAL_DETAILS.getRoute(cardID), basePath), {forceReplace: true});
	}}
	isLoading={privatePersonalDetails?.isLoading}
	/>
	);

Since params is optional, requestValidateCodeAction forwards null as the reason to the backend command:

App/src/libs/actions/User.ts

Lines 517 to 518 in 007bd53

	*/
	function requestValidateCodeAction(params?: ResendValidateCodeParams) {

With no reason supplied, the backend falls back to its generic "Log in to your account or access a secure feature." copy instead of the reveal-specific message — this is the exact defect described in the issue. Note that this same page is also reused for the physical-card "ship" flow, and it already branches on isVirtualCard in handleSubmitForm to pick the reveal-vs-ship submission logic, so the reveal-specific branch is the right place to add the missing reason.

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

In MissingPersonalDetailsMagicCodePage.tsx, pass the same REVEAL_CARD_DETAILS reason (with the card ID) that ExpensifyCardVerifyAccountPage.tsx already uses, but only for the virtual-card/reveal path — the existing isVirtualCard flag (already computed on line 58 and used to branch handleSubmitForm) tells us which case we're in:

App/src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx

Line 111 in 007bd53

sendValidateCode={() => requestValidateCodeAction()}

sendValidateCode={() =>
    requestValidateCodeAction(isVirtualCard ? {reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number(cardID)} : undefined)
}

This also requires importing the expensify-common CONST (aliased as COMMON_CONST, matching the existing convention in ExpensifyCardVerifyAccountPage.tsx) at the top of the file:

import {CONST as COMMON_CONST} from 'expensify-common';

With this change, the magic-code request issued from the "Add personal info" reveal flow carries the same reasonCode/reasonCardID as the direct reveal flow, so the backend renders the correct "Reveal details for your Expensify card ending in NNNN" copy in the email regardless of which path (with or without missing personal details) the user took to get to the magic-code screen.

[dilshodmackbook-sketch]

Proposal

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

When a user reveals their virtual Expensify card details, the magic-code email is supposed to read "...trying to: • Reveal details for your Expensify card ending in NNNN" (delivered by #96224). But when the account is missing personal details/address, the email instead falls back to the generic copy "...log in to your account or access a secure feature."

(The "Add personal info form is displayed" part of the report is expected: for an account with no personal details, Reveal must collect them first — see index.tsx#L531-L534. The real defect is the email content sent from that flow.)

What is the root cause of that problem?

The Reveal button has two entry points into the magic-code step, and only one of them carries the reveal reason.

When personal details are already present, Reveal routes to ExpensifyCardVerifyAccountPage, which #96224 correctly migrated to send the reason — ExpensifyCardVerifyAccountPage.tsx#L72:

sendValidateCode={() => requestValidateCodeAction({reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number.parseInt(cardID, 10)})}

But when personal details/address are missing, Reveal instead diverts to the MissingPersonalDetails flow (index.tsx#L531-L534), whose magic-code page still requests the code with no reason — MissingPersonalDetailsMagicCodePage.tsx#L111:

sendValidateCode={() => requestValidateCodeAction()}

That page is a genuine card-reveal path — its submit handler calls setPersonalDetailsAndRevealExpensifyCard when isVirtualCard is true (#L89-L100) — but because it calls requestValidateCodeAction() argument-less, the backend gets an empty reasonCode and applies the generic fallback copy. #96224 migrated the direct-reveal page but left this parallel reveal entry point on the legacy call.

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

Pass the reveal_card_details reason (with reasonCardID) from MissingPersonalDetailsMagicCodePage when the flow is actually revealing a virtual card, mirroring what ExpensifyCardVerifyAccountPage already does. The physical-card shipping path (updatePersonalDetailsAndShipExpensifyCards) is not a reveal, so it keeps the argument-less generic call.

Add the import:

import {CONST as COMMON_CONST} from 'expensify-common';

Then update sendValidateCode at MissingPersonalDetailsMagicCodePage.tsx#L111:

sendValidateCode={() =>
    isVirtualCard
        ? requestValidateCodeAction({reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number(cardID)})
        : requestValidateCodeAction()
}

isVirtualCard is already computed in this component (#L58), and the ResendValidateCodeParams discriminated union already enforces that reveal_card_details is paired with a reasonCardID, so this is type-safe with no signature changes.

What specific scenarios/tests should we add to cover this to prevent regressions?

Add a test around MissingPersonalDetailsMagicCodePage that renders it for a virtual card with missing personal details, triggers the resend, and asserts requestValidateCodeAction is called with {reasonCode: 'reveal_card_details', reasonCardID: <cardID>}; and a second case for a physical (non-virtual) card asserting it is called with no reason. This locks both branches so a future refactor can't silently drop the reason again.

What alternative solutions did you explore? (Optional)

Fix at the routing layer instead of the call site. Rather than migrating the standalone magic-code page, we could change the Reveal handler at index.tsx#L531-L534 so a missing-details reveal runs through the combined SET_PERSONAL_DETAILS_AND_REVEAL_CARD_DETAILS MFA scenario (already used for UK/EU cards just below it) instead of diverting to the standalone MissingPersonalDetails page. That keeps the reveal inside one authenticated flow and would fix the copy as a side effect. It's a heavier change though — it alters the step-4 UX for every new account and reroutes a shared flow, so I'd keep it as a follow-up and prefer the targeted call-site fix, which mirrors the exact pattern #96224 established in ExpensifyCardVerifyAccountPage and stays type-safe against ResendValidateCodeParams.

Centralize the reason inside the reveal action (e.g. have setPersonalDetailsAndRevealExpensifyCard own it) so every entry point inherits it. Rejected because the email is triggered at code-request time (requestValidateCodeAction → RESEND_VALIDATE_CODE), which is decoupled from the submit action — the reason has to be set where the code is requested, not where the card is revealed.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When a user clicks "Reveal" on an Expensify card to see its details, the code checks whether address and personal details are complete before requesting a magic code. If details are missing, the user is sent to the "Add personal info" form instead of receiving the magic code prompt. This causes two failures:

1. Wrong form shown: The user sees the missing personal details form instead of the magic code input screen.
2. Wrong email sent: Because the validation context never enters the card-reveal flow, the backend sends a generic "Log in to your account" email instead of "Reveal details for your Expensify card ending in NNNN".

The mechanism: In ExpensifyCardPage, line 531 checks areAddressAndPersonalDetailsMissing(privatePersonalDetails) and navigates to the missing details page before even calling requestValidateCodeAction(). This check was introduced in commit 4214575, which changed from the less-strict arePersonalDetailsMissing() to areAddressAndPersonalDetailsMissing() — a condition that fails for users with incomplete address fields.

App/src/pages/settings/Wallet/ExpensifyCardPage/index.tsx

Lines 525 to 551 in fd467ee

	onPress={() => {
	if (isAccountLocked) {
	showLockedAccountModal();
	return;
	}
	if (areAddressAndPersonalDetailsMissing(privatePersonalDetails)) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.MISSING_PERSONAL_DETAILS.getRoute(String(card.cardID))));
	return;
	}
	if (isUkEuExpensifyCard(card)) {
	const personalDetailsForm = getNormalizedSubPageValues(privatePersonalDetails);
	const personalDetailsParams = buildSetPersonalDetailsAndShipExpensifyCardsParams(personalDetailsForm, countryCode);
	executeScenario(CONST.MULTIFACTOR_AUTHENTICATION.SCENARIO.SET_PERSONAL_DETAILS_AND_REVEAL_CARD_DETAILS, {
	...personalDetailsParams,
	cardID: String(card.cardID),
	});
	return;
	}
	if (route.name === SCREENS.DOMAIN_CARD.DOMAIN_CARD_DETAIL) {
	Navigation.navigate(ROUTES.SETTINGS_DOMAIN_CARD_CONFIRM_MAGIC_CODE.getRoute(String(card.cardID)));
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAIN_CARD_CONFIRM_MAGIC_CODE.getRoute(String(card.cardID)));
	}}

The expected flow (used by other card verification scenarios) is: request magic code first → show magic code prompt → on successful validation, then check for missing details inside the callback. This ensures the backend receives the correct context and sends the right email.

Comparison with working siblings: Travel card CVV reveal and PIN reveal do not check for missing details upfront; they go straight to the magic code or MFA flow. This is why they send the correct email.

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

The fix moves the missing-details check from the reveal-button handler into the magic code validation callback. We need to:

1. Remove the early check from the Reveal button handler

In ExpensifyCardPage line 531-534, delete the check that navigates to missing details:

// DELETE THIS
if (areAddressAndPersonalDetailsMissing(privatePersonalDetails)) {
    Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.MISSING_PERSONAL_DETAILS.getRoute(String(card.cardID))));
    return;
}

Instead, proceed directly to the magic code flow for all non-UK/EU cards:

// REPLACE WITH:
Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAIN_CARD_CONFIRM_MAGIC_CODE.getRoute(String(card.cardID)));

For UK/EU cards, the SET_PERSONAL_DETAILS_AND_REVEAL_CARD_DETAILS MFA scenario already handles the missing-details submission as part of the challenge, so no change needed there.

2. Add the missing-details check in the magic code callback

In ExpensifyCardVerifyAccountPage.tsx, line 46-65, add a guard in handleRevealCardDetails before calling the reveal API:

const handleRevealCardDetails = (validateCode: string) => {
    // Check for missing details now, after MFA succeeds
    if (areAddressAndPersonalDetailsMissing(privatePersonalDetails)) {
        Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.MISSING_PERSONAL_DETAILS.getRoute(cardID)));
        return;
    }

    setVirtualCardDetailsLoading(cardID, true);
    // ... rest of the function
};

Import areAddressAndPersonalDetailsMissing and createDynamicRoute in that file.

Why it's safe:

• The magic code request is sent regardless of personal details state, so the backend receives the correct revealExpensifyCardDetails context and sends the correct email.
• The missing-details check still happens, just after MFA validation instead of before it.
• Users who have complete details skip the missing-details page entirely (no regression).
• Users who need to add details are prompted after they've proven their identity with the magic code.
• The callback fires inside the MFA modal, so the user's flow is still protected.

Result: The magic code email now arrives with the correct card-specific context, and users are routed to the missing-details form only after MFA succeeds, not before the magic code is sent.

What alternative solutions did you explore? (Optional)

• Check and collect missing details upfront via a form step before magic code: Adds friction for users who already have complete details; defeats the purpose of the MFA context being sent first.
• Remove the address-details check entirely: Risky — the backend asserts on full address fields, so missing data would hit a backend error instead of a graceful UI prompt.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-21 09:50:28 UTC.

Proposal

What is the root cause of that problem?

The report contains two behaviours, and only the second is a bug.

1. The "Add personal info" form at step 4 is intentional, not a regression.

The Reveal handler checks whether the cardholder details the reveal command requires are present, and routes to the personal-details flow when they are missing. A freshly created account that has only validated its email has no legal name, phone number, date of birth or address, so it correctly lands on that form.

App/src/pages/settings/Wallet/ExpensifyCardPage/index.tsx

Lines 529 to 535 in 7c2a00b

	}
	if (areAddressAndPersonalDetailsMissing(privatePersonalDetails)) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.MISSING_PERSONAL_DETAILS.getRoute(String(card.cardID))));
	return;
	}

I do not think the Expected Result for step 4 should be restored — it predates that flow.

2. The generic email is a real bug, and I traced it to a revert/re-land cycle that skipped exactly one call site.

The reasonCode parameter has had a churn cycle on main:

• PR [Payment due @daledah] Add reasonCode parameter to (some) ResendValidateCode calls #90726 added reasonCode to the ResendValidateCode call sites (bdf92ed0ce3)
• PR [CP Staging] Revert "Add reasonCode parameter to (some) ResendValidateCode calls" #96134 reverted it wholesale (6358bc12e27, 14 Jul)
• PR [Payment due @daledah] Bring back validateCode reasonCode #96224 re-landed it (2434b3fbba2, 20 Jul) — the PR this bug was filed against

Separately and concurrently, PR #91634 introduced the missing-personal-details reveal flow, including MissingPersonalDetailsMagicCodePage. Because that page did not exist in #90726's diff, neither the revert nor the re-land ever touched it. On current main it is the only card-reveal magic-code page that still requests a code with no reason:

App/src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx

Lines 108 to 113 in 7c2a00b

	<ValidateCodeActionContent
	title={translate('cardPage.validateCardTitle')}
	descriptionPrimary={translate('cardPage.enterMagicCode', primaryLogin ?? '')}
	sendValidateCode={() => requestValidateCodeAction()}
	validateCodeActionErrorField="personalDetails"
	handleSubmitForm={handleSubmitForm}

Its two siblings both received the reason back in #96224:

App/src/pages/settings/Wallet/ExpensifyCardPage/ExpensifyCardVerifyAccountPage.tsx

Lines 69 to 73 in 7c2a00b

	<ValidateCodeActionContent
	title={translate('cardPage.validateCardTitle')}
	descriptionPrimary={translate('cardPage.enterMagicCode', primaryLogin)}
	sendValidateCode={() => requestValidateCodeAction({reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number.parseInt(cardID, 10)})}
	validateCodeActionErrorField="revealExpensifyCardDetails"

App/src/pages/settings/Wallet/TravelCVVPage/TravelCVVVerifyAccountPage.tsx

Lines 64 to 70 in 7c2a00b

	return (
	<ValidateCodeActionContent
	title={translate('cardPage.validateCardTitle')}
	descriptionPrimary={translate('cardPage.enterMagicCode', primaryLogin ?? '')}
	sendValidateCode={() => requestValidateCodeAction({reasonCode: CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: travelCard.cardID})}
	validateCodeActionErrorField="revealExpensifyCardDetails"
	handleSubmitForm={handleRevealCardDetails}

With no argument, the action falls back to null, so ResendValidateCode reaches the backend carrying no reason at all and the backend has nothing to key the templated email off — it sends the generic "Log in to your account or access a secure feature."

App/src/libs/actions/User.ts

Lines 566 to 571 in 7c2a00b

	},
	},
	];
	API.write(WRITE_COMMANDS.RESEND_VALIDATE_CODE, params ?? null, {optimisticData, successData, failureData});
	}

I confirmed this empirically rather than by inspection. I added a Jest test that renders the page with a virtual card seeded in CARD_LIST and asserts the payload handed to API.write. Against unpatched main it fails with:

Expected: {"reasonCardID": 885522, "reasonCode": "reveal_card_details"}
Received: null

That null is precisely the wire payload that produces the wrong email.

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

I think MissingPersonalDetailsMagicCodePage should supply the reveal reason and the card ID when the card is virtual, mirroring the two sibling pages, and keep the generic request for the physical-card shipping flow — that flow's magic code authorises shipping, not a reveal, so attaching a reveal reason there would make its email wrong in the opposite direction.

The page already derives isVirtualCard from the target card's nameValuePairs, so no new state is needed. In sendValidateCode, instead of calling requestValidateCodeAction() unconditionally, it should pass the reveal parameters when isVirtualCard is true and undefined otherwise:

sendValidateCode={() =>
    requestValidateCodeAction(
        isVirtualCard
            ? {reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number.parseInt(cardID, 10)}
            : undefined,
    )
}

I would use Number.parseInt(cardID, 10) rather than Number(cardID) so the conversion matches ExpensifyCardVerifyAccountPage exactly, and the discriminated ResendValidateCodeParams union already forces reasonCardID to be present whenever REVEAL_CARD_DETAILS is used, so the two can never drift apart.

Worth noting: this same callback also backs the "Didn't receive a magic code?" resend link in BaseValidateCodeForm, so the fix corrects the resent email too, not just the first one.

App/src/components/ValidateCodeActionModal/ValidateCodeForm/BaseValidateCodeForm.tsx

Lines 269 to 271 in 7c2a00b

	const resendValidateCode = () => {
	sendValidateCode();
	inputValidateCodeRef.current?.clear();

For coverage I would add a unit test with both branches — a virtual card sends REVEAL_CARD_DETAILS plus its numeric card ID, a physical card sends null — asserting on the API.write payload rather than on the component, so it pins the actual contract with the backend. I have this written and verified red/green.

Since the "Add personal info" step is working as designed, I would also suggest updating the Expected Result for step 4 so this does not get re-reported.

What alternative solutions did you explore? (Optional)

I considered skipping the personal-details form and sending every card straight to the magic-code page, which would match the issue's Expected Result literally. I do not recommend it: the reveal command requires those cardholder fields, and the guard exists specifically to stop incomplete data reaching the backend.

I also considered defaulting the reason inside requestValidateCodeAction itself so no call site can forget it. I rejected that because the action is shared by contact-method, account-validation, delegate and card-issuance flows, each of which needs a different reason — a default would silently mislabel those emails instead. Given this bug was caused by one call site being missed, the durable follow-up is to make reasonCode a required parameter once every remaining call site has been migrated, which the ResendValidateCodeNotYetImplementedParams variant is already staged for.

[lorretheboy]

Proposal

What is the root cause of that problem?

When an account has no personal details on file, clicking "Reveal" is routed to the shared MissingPersonalDetails flow (this is intended — the reveal command needs legal name/DOB/address), and it ends on MissingPersonalDetailsMagicCodePage. That page requests the magic code with no reason:

App/src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx

Line 111 in 007bd53

sendValidateCode={() => requestValidateCodeAction()}

so requestValidateCodeAction forwards null to RESEND_VALIDATE_CODE and the backend sends the generic "log in to your account or access a secure feature" copy instead of the reveal-specific email:

App/src/libs/actions/User.ts

Line 570 in 007bd53

API.write(WRITE_COMMANDS.RESEND_VALIDATE_CODE, params ?? null, {optimisticData, successData, failureData});

The obvious patch is to branch on isVirtualCard at that call site. But there is a second, easy-to-miss reason this page in particular ships the wrong email, and it's the part that makes a naive isVirtualCard gate unreliable on the exact platform in the report (web, refresh mid-flow): the reveal intent is derived from a different Onyx key than the one that gates the send.

isVirtualCard is read from CARD_LIST:

App/src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx

Lines 56 to 58 in 007bd53

	const targetCardSelector = useCallback((cardList: OnyxEntry<CardList>) => (cardID ? cardList?.[cardID] : undefined), [cardID]);
	const [targetCard] = useOnyx(ONYXKEYS.CARD_LIST, {selector: targetCardSelector});
	const isVirtualCard = !!targetCard?.nameValuePairs?.isVirtual;

but the initial magic-code request is fired from an effect in ValidateCodeActionContent that only waits for VALIDATE_ACTION_CODE to hydrate — not CARD_LIST — and fires exactly once (guarded by firstRenderRef):

App/src/components/ValidateCodeActionModal/ValidateCodeActionContent.tsx

Lines 42 to 59 in 007bd53

	useEffect(() => {
	// Wait for Onyx to hydrate before deciding, otherwise on reload we read undefined and wrongly re-send
	if (isLoadingOnyxValue(validateCodeActionMetadata) || !firstRenderRef.current) {
	return;
	}
	firstRenderRef.current = false;
	// The magic code is account-level, so skip sending if one was already requested within the resend window (e.g. a page reload)
	const requestedAt = validateCodeAction?.lastValidateCodeRequestedAt;
	const sentRecently = !!requestedAt && Date.now() - requestedAt < CONST.REQUEST_CODE_DELAY * CONST.MILLISECONDS_PER_SECOND;
	if (sentRecently) {
	return;
	}
	sendValidateCode();
	// We only want to decide whether to send once Onyx has hydrated, so we depend on the hydration metadata rather than the value
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [sendValidateCode, validateCodeActionMetadata]);

Onyx hydrates keys independently. On a fresh page load / browser refresh at the confirm-magic-code URL (a real scenario — magic-code emails take time to arrive, and that same effect is explicitly written to re-send after a reload), if VALIDATE_ACTION_CODE hydrates before CARD_LIST, then at send time targetCard is still undefined, isVirtualCard is false, and the one-shot effect sends the generic email — even with an isVirtualCard branch in place. Because the send only fires once, the correct reason never goes out for that magic code.

So the durable root cause is: the reveal reason must be resolved before the single initial send fires, and the naive gate doesn't guarantee that.

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

Two small changes in MissingPersonalDetailsMagicCodePage.tsx:

1. Pass the reveal reason for the virtual-card branch (the ship branch stays reason-less):

sendValidateCode={() =>
    requestValidateCodeAction(
        isVirtualCard ? {reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number(cardID)} : undefined,
    )
}

2. Don't mount ValidateCodeActionContent (which owns the one-shot send effect) until CARD_LIST has hydrated, so isVirtualCard is resolved before the initial send — capture the selector's loading metadata and short-circuit on it:

App/src/pages/MissingPersonalDetails/MissingPersonalDetailsMagicCodePage.tsx

Lines 56 to 58 in 007bd53

	const targetCardSelector = useCallback((cardList: OnyxEntry<CardList>) => (cardID ? cardList?.[cardID] : undefined), [cardID]);
	const [targetCard] = useOnyx(ONYXKEYS.CARD_LIST, {selector: targetCardSelector});
	const isVirtualCard = !!targetCard?.nameValuePairs?.isVirtual;

const [targetCard, targetCardMetadata] = useOnyx(ONYXKEYS.CARD_LIST, {selector: targetCardSelector});
// ...
if (isLoadingOnyxValue(targetCardMetadata)) {
    return <FullscreenLoadingIndicator />;
}

New imports:

import FullscreenLoadingIndicator from '@components/FullscreenLoadingIndicator';
import isLoadingOnyxValue from '@src/types/utils/isLoadingOnyxValue';
import {CONST as COMMON_CONST} from 'expensify-common';

This mirrors the reason the direct path already sends:

App/src/pages/settings/Wallet/ExpensifyCardPage/ExpensifyCardVerifyAccountPage.tsx

Line 72 in 007bd53

sendValidateCode={() => requestValidateCodeAction({reasonCode: COMMON_CONST.VALIDATE_CODE_REASONS.REVEAL_CARD_DETAILS, reasonCardID: Number.parseInt(cardID, 10)})}

but additionally guarantees the reason is correct on the very first (and post-refresh) send, which the plain call-site branch does not. ValidateCodeActionContent already handles its own hydration gate for VALIDATE_ACTION_CODE; this adds the matching gate for the CARD_LIST value the reason depends on.

What specific scenarios/tests should we add to cover this to prevent regressions?

• Render the page for a virtual card with CARD_LIST already hydrated → assert requestValidateCodeAction is called with {reasonCode: 'reveal_card_details', reasonCardID}.
• Render it with CARD_LIST hydrating after VALIDATE_ACTION_CODE → assert the send is deferred until the card resolves and still goes out with the reveal reason (locks the race described above).
• Render it for a physical (ship) card → assert the send carries no reason.

What alternative solutions did you explore? (Optional)

• Only add the isVirtualCard branch at the call site, without the hydration gate. This is the smaller change, but as shown above it can still send the generic email on a refresh/cold load because the send effect fires before CARD_LIST hydrates — so it doesn't fully close the bug on web.
• Restructure the flow so the missing-details check moves after the magic-code step (request the code first via ExpensifyCardVerifyAccountPage, then collect details). Larger, riskier change to a working gate, and the backend expects full address data on the reveal command, so I preferred the contained fix.

[melvin-bot]

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