[Due for payment 2026-09-15] Code does not arrive when adding contact method with new user

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.55-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: #97803
Email or phone of affected tester (no customers): emady.syed1234+ok4@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

1. Open staging.new.expensify and login as new user
2. Go to Profile > Add contact method
3. Click on new contact method
4. Enter verification code

Expected Result:

After validating the new user with code, the 2nd code to create new contact method should arrive in mailbox.

Actual Result:

After validating the new user with code, the 2nd code to create new contact method does not arrive in mailbox

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7236199_1787045293057.Recording__1086.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Vincenzo Godoy
Bug ID: 7236199

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022089700188348167108
• Upwork Job ID: 2089700188348167108
• Last Price Increase: 2026-08-18

Issue Owner

Current Issue Owner: @DylanDylann

[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/9a31be37b48fbff87bf9addbbced5070fc10b0030c4917a561b251d5bb16c284

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user adds a new contact method, the App never requests the magic code for the new address. After AddNewContactMethod succeeds, DynamicNewContactMethodPage.tsx:130 navigates to the details page passing shouldSkipInitialValidation = true. That flag suppresses the on‑mount code request in ValidateCodeActionForm/index.tsx:31-33, so RequestContactMethodValidateCode is never sent for the new email. The validateCode passed to AddNewContactMethod is the current user's identity‑verification code (from their primary login) — it does not trigger a code to the new address.

This is a regression from the migration to the "Dynamic" contact‑method pages. The exact same bug was fixed before in the legacy flow via PR #67721 (issue #65259) using resetValidateActionCodeSent() on NewContactMethodPage.tsx. That legacy page — and its fix — were deleted when the Dynamic pages replaced them, and no equivalent was carried over.

Investigation details & evidence

App flow (new user adds a contact method):

1. Identity step sends a code to the primary login (ResendValidateCode).
2. User enters that code → addNewContactMethod(email, primaryActionCode) → AddNewContactMethod API command.
3. On success, navigate to details with shouldSkipInitialValidation=true → the client‑side RequestContactMethodValidateCode for the new address is skipped → no code email.

Why it's App-side, not backend: the backend has never auto‑sent the code on AddNewContactMethod — the prior fix (PR #67721) was purely an App change that ensured the App itself requested the code. Dropping that request re-introduces the identical symptom.

Corroborating asymmetry in the codebase: opening an existing/pending method from the list navigates without the flag (DynamicContactMethodsPage.tsx:82), so that path does auto-send. Only the just-added path passes true.

Confidence: Medium‑High. Two independent code investigations converged on this. I could not get production log confirmation (VictoriaLogs was unavailable this run), so the one remaining assumption to verify is that backend AddNewContactMethod still does not auto-send the code — which the history of #65259/#67721 strongly supports.

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

Make the just-added navigation request the new-address code on mount — i.e. do not pass shouldSkipInitialValidation=true on the post-add navigation at DynamicNewContactMethodPage.tsx:130 (pass false / omit it), so ValidateCodeActionForm fires sendValidateCode() → RequestContactMethodValidateCode for the new address, matching the behavior the legacy flow guaranteed.

Whoever implements should double-check why the flag was set to true in the first place: if it was to avoid a double-send, confirm the backend isn't already sending one code, so the fix doesn't reintroduce a "code sent twice" bug (cf. #56601). If a double-send is a risk, port the legacy resetValidateActionCodeSent() approach instead of simply flipping the flag.

What alternative solutions did you explore? (Optional)

Re-introduce a resetValidateActionCodeSent()-equivalent in the Dynamic add flow (the mechanism PR #67721 used) rather than changing the skip flag — functionally equivalent, safer if the backend ever does send one code.

Related issues: #65259 and #67200 were the prior occurrences of this exact bug in the legacy flow (both fixed/closed). This appears to be the same defect resurfacing after the Dynamic-pages migration.

---

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

[melvin-bot]

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

[melvin-bot]

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

[yusufdeveloper2903]

Melvin's root cause states that the backend "has never auto-sent the code on AddNewContactMethod", but the shouldSkipInitialValidation=true it proposes to drop is itself the merged fix for #56601, added because the backend does email the code to the new address and the client's own RequestContactMethodValidateCode was duplicating it:

1d2fbf7

Dropping that flag reverts #56601, so every user adding a secondary contact method receives two magic codes at the new address again — and since the flag is passed unconditionally on that navigation, it also cannot explain why this only reproduces for a new, unvalidated user.

[melvin-bot]

@DylanDylann Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[nkdengineer]

The Melvin analysis is incorrect. DynamicNewContactMethodConfirmValidateCodePage is using ValidateCodeActionContent which is a different code form.

App/src/pages/settings/Profile/Contacts/DynamicNewContactMethodConfirmValidateCodePage.tsx

Line 43 in 7af64f2

<ValidateCodeActionContent

We only skip sending a new request on mount if the lastValidateCodeRequestedAt is less than REQUEST_CODE_DELAY. After validating the account, lastValidateCodeRequestedAt is not cleared; then, on DynamicNewContactMethodConfirmValidateCodePage, no request magic code API is sent. We should clear lastValidateCodeRequestedAt in successData when the API used magic code is successful to not prevent the next action that requires the magic code like this case.

App/src/components/ValidateCodeActionModal/ValidateCodeActionContent.tsx

Lines 42 to 65 in 7af64f2

	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 validateCode 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]);
	const hide = useCallback(() => {
	clearError();
	onClose?.();
	}, [onClose, clearError]);

[DylanDylann]

🆘 C+ Help Wanted