[Due for payment 2026-03-17] Contact method - After going online, user not redirected to contact method list on verifying secondary login

[lanitochka17]

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.3.11-15
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-3778/folder/13176687/41236653/1155364430?p=2
Email or phone of affected tester (no customers): kiatest.78+ck1218251@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/Chrome, iPhone 16/iOS 18.7.1, Pixel 8a/Android 16
App Component: User Settings

Action Performed:

1. Navigate to staging.new.expensify.com
2. Navigate to account settings > Profile
3. Click on "Contact Method"
4. Enter the magic code sent to main contact
5. Add a email as secondary contact method
6. Disable the internet connection
7. Verify the "Verify" button is disabled
8. Paste the magic code
9. Go online in troubleshoot modal (CTRL+D)
10. Wait for the troubleshoot modal to dismiss automatically (In my case, once I turned OFF Force offline toggle, modal dismissed automatcally)

Expected Result:

User should be redirected to contact methods after going online list on verifying secondary login

Actual Result:

After going online, user not redirected to contact method list on verifying secondary login. User

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7062089_1769790895327.15.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @brianlee-expensify

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @brianlee-expensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[daledah]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-30 18:12:31 UTC.

Proposal

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

After going online, user not redirected to contact method list on verifying secondary login

What is the root cause of that problem?

The root cause is in the NewContactMethodConfirmMagicCodePage component. When the user pastes the magic code while offline, the verifyAddSecondaryLoginCode API call is queued in the SequentialQueue. The optimistic data sets isLoading: true but does NOT set isVerifiedValidateActionCode: true - that only happens in the success data.

App/src/libs/actions/User.ts

Lines 1618 to 1658 in 80dc863

	function verifyAddSecondaryLoginCode(validateCode: string) {
	resetValidateActionCodeSent();
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.PENDING_CONTACT_ACTION>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PENDING_CONTACT_ACTION,
	value: {
	validateActionCode: validateCode,
	isLoading: true,
	errorFields: {
	validateActionCode: null,
	},
	},
	},
	];
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.PENDING_CONTACT_ACTION>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PENDING_CONTACT_ACTION,
	value: {
	isVerifiedValidateActionCode: true,
	isLoading: false,
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.PENDING_CONTACT_ACTION>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PENDING_CONTACT_ACTION,
	value: {
	isVerifiedValidateActionCode: false,
	isLoading: false,
	},
	},
	];
	const parameters: VerifyAddSecondaryLoginCodeParams = {validateCode};
	API.write(WRITE_COMMANDS.VERIFY_ADD_SECONDARY_LOGIN_CODE, parameters, {optimisticData, successData, failureData});

The useEffect in NewContactMethodConfirmMagicCodePage that handles the navigation depends on pendingContactAction?.isVerifiedValidateActionCode:

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

Lines 26 to 31 in 80dc863

	useEffect(() => {
	if (!pendingContactAction?.isVerifiedValidateActionCode) {
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_NEW_CONTACT_METHOD.getRoute(navigateBackTo));
	}, [navigateBackTo, pendingContactAction?.isVerifiedValidateActionCode]);

When the troubleshoot modal is open and the user toggles OFF "Force offline", the modal auto-dismisses. At this point, navigation state changes occur (modal dismissing and returning to the previous screen). Meanwhile, the queued API request starts processing and when it succeeds, isVerifiedValidateActionCode is set to true.

The issue is that during the modal dismiss animation and navigation state transition, the useEffect may not properly trigger the navigation because the component's navigation context is in an unstable state during the transition.

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

We should use Navigation.setNavigationActionToMicrotaskQueue to ensure the navigation is executed after the current navigation state has settled. This pattern is already used in other parts of the codebase (e.g., BaseDomainVerifiedPage) to handle similar timing issues.

diff --git a/src/pages/settings/Profile/Contacts/NewContactMethodConfirmMagicCodePage.tsx b/src/pages/settings/Profile/Contacts/NewContactMethodConfirmMagicCodePage.tsx
index abc1234..def5678 100644
--- a/src/pages/settings/Profile/Contacts/NewContactMethodConfirmMagicCodePage.tsx
+++ b/src/pages/settings/Profile/Contacts/NewContactMethodConfirmMagicCodePage.tsx
@@ -26,7 +26,7 @@ function NewContactMethodConfirmMagicCodePage({route}: NewContactMethodConfirmMa
     useEffect(() => {
         if (!pendingContactAction?.isVerifiedValidateActionCode) {
             return;
         }
-        Navigation.navigate(ROUTES.SETTINGS_NEW_CONTACT_METHOD.getRoute(navigateBackTo));
+        Navigation.setNavigationActionToMicrotaskQueue(() => Navigation.navigate(ROUTES.SETTINGS_NEW_CONTACT_METHOD.getRoute(navigateBackTo)));
     }, [navigateBackTo, pendingContactAction?.isVerifiedValidateActionCode]);

This ensures the navigation action is queued to run after the current microtask, allowing any pending navigation state changes (like modal dismissal) to complete first.

What alternative solutions did you explore? (Optional)

We should use the useNetwork hook to detect when the network comes back online and trigger the navigation if isVerifiedValidateActionCode is already true. This ensures that even if the navigation was missed during the initial state change, it will be triggered when the network reconnects.

+    const navigateToNewContactMethod = useCallback(() => {
+        if (!pendingContactAction?.isVerifiedValidateActionCode) {
+            return;
+        }
+        Navigation.navigate(ROUTES.SETTINGS_NEW_CONTACT_METHOD.getRoute(navigateBackTo));
+    }, [navigateBackTo, pendingContactAction?.isVerifiedValidateActionCode]);
+
+    useNetwork({onReconnect: navigateToNewContactMethod});

[cosmicvulpes]

Proposal

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

When a user adds a secondary contact method and enters the verification magic code while offline, then goes back online via the troubleshoot modal, they are not redirected to the contact methods list as expected. The verification appears to complete but the user remains stuck on the verification page.

What is the root cause of that problem?

The root cause is a stale closure issue in the MagicCodeInput component.

In src/components/MagicCodeInput.tsx, the validateAndSubmit function is defined BEFORE isOffline is retrieved from useNetwork:

const validateAndSubmit = () => {
    // ...
    if (wasSubmitted || !shouldSubmitOnComplete || ... || isOffline) {  // isOffline captured here
        return;
    }
    // ...
};

const {isOffline} = useNetwork({onReconnect: validateAndSubmit});  // isOffline assigned here

When the network reconnects:

1. React re-renders the component due to the isOffline state change
2. validateAndSubmit is recreated, but it captures isOffline from the PREVIOUS render (when it was true)
3. useNetwork calls onReconnect (which points to the new validateAndSubmit)
4. The stale isOffline = true causes validateAndSubmit to return early without submitting

Since the form never submits, validatedDate is never set on the login data, and the navigation effect in ContactMethodDetailsPage that watches for validatedDate never triggers.

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

1. Move the useNetwork() call BEFORE the validateAndSubmit function definition so isOffline is available with the correct value
2. Add a skipOfflineCheck parameter to validateAndSubmit
3. Use a separate useNetwork call for the onReconnect callback that passes skipOfflineCheck: true

The fix ensures that when onReconnect is triggered (which only happens when transitioning from offline to online), we skip the offline check entirely since we know we're already online at that point.

Modified code in MagicCodeInput.tsx:

const {isOffline} = useNetwork();

const validateAndSubmit = (skipOfflineCheck = false) => {
    const numbers = decomposeString(value, maxLength);
    if (wasSubmitted || !shouldSubmitOnComplete || ... || (!skipOfflineCheck && isOffline)) {
        return;
    }
    // ... rest of the function
};

// onReconnect only fires when coming back online, so skip the offline check
useNetwork({onReconnect: () => validateAndSubmit(true)});

What alternative solutions did you explore? (Optional)

1. Using a ref for isOffline: Could use useRef to store isOffline and update it on every render, then access isOfflineRef.current in validateAndSubmit. However, this adds complexity and indirection.

2. Moving validateAndSubmit to useCallback with proper dependencies: This would solve the stale closure but might cause unwanted re-submissions when dependencies change.

The chosen solution is cleaner because:

• It uses the semantic meaning of onReconnect (we know we're online when it fires)
• It doesn't require additional refs or complex dependency management
• It's explicit about when to skip the offline check

[samranahm]

Proposal

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

When adding a secondary contact method: user goes to Contact Method, enters magic code for main contact, adds an email as secondary, goes offline, pastes the magic code (Verify disabled), then goes back online via the troubleshoot modal. After the modal dismisses, the user is not redirected to the contact method list / next step even though verification has (or will) succeed.

What is the root cause of that problem?

The redirect after validation is driven by a useEffect that runs when isUserValidated (or isVerifiedValidateActionCode on the confirm-magic-code page) becomes true. When the user goes back online via the troubleshoot modal, validation can complete while the modal is still open or right as it closes. In that case (1) the effect may run while the modal is on top, so Navigation.navigate doesn’t result in the expected screen, or (2) the modal dismisses and the verify/confirm screen never runs the navigation again because the effect already ran. So the post-validation redirect is lost.

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

Run the same redirect logic when the verify/confirm screen gains focus (e.g. after the troubleshoot modal closes), not only when the validation state flips. Use useFocusEffect so that when the screen is focused and the user is already in a validated state, we perform the navigation. That way, after the modal dismisses and the verify page is visible again, we still redirect to the contact method list (or next step). Keep the existing useEffect so we still redirect immediately when validation succeeds and no modal is open.

Apply this in:

• VerifyAccountPageBase when focused and isUserValidated, run the same navigation as in the current effect.
• NewContactMethodConfirmMagicCodePage when focused and isVerifiedValidateActionCode, navigate to SETTINGS_NEW_CONTACT_METHOD (same as current effect).

Use a ref (e.g. hasNavigated) to avoid double navigation when both the effect and the focus callback could run.

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.

[abbasifaizan70]

Proposal

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

When a user adds a secondary contact method (e.g. email), goes through the magic-code verification step, and the connection is disabled during that step, the user is not redirected to the contact methods list after going back online and successfully verifying.

What is the root cause of that problem?

The redirect after secondary-login (magic code) verification is implemented in NewContactMethodConfirmMagicCodePage.tsx via a useEffect that depends on pendingContactAction?.isVerifiedValidateActionCode. When that becomes true, the code navigates to ROUTES.SETTINGS_NEW_CONTACT_METHOD (the “new contact method” form), not to the contact methods list.

1. Wrong redirect target (RCA code)

The effect that runs on verification success navigates to SETTINGS_NEW_CONTACT_METHOD instead of the contact methods list:

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

Lines 26 to 31 in 6e6fec5

	useEffect(() => {
	if (!pendingContactAction?.isVerifiedValidateActionCode) {
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_NEW_CONTACT_METHOD.getRoute(navigateBackTo));
	}, [navigateBackTo, pendingContactAction?.isVerifiedValidateActionCode]);

2. Success data that sets the flag

When the API call succeeds, successData sets isVerifiedValidateActionCode: true in Onyx, which triggers the effect above:

App/src/libs/actions/User.ts

Lines 1634 to 1643 in 6e6fec5

	const successData: Array<OnyxUpdate<typeof ONYXKEYS.PENDING_CONTACT_ACTION>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PENDING_CONTACT_ACTION,
	value: {
	isVerifiedValidateActionCode: true,
	isLoading: false,
	},
	},
	];

Two factors can explain the observed behavior:

1. Wrong redirect target: The expected behavior is to land on the contact methods list (SETTINGS_CONTACT_METHODS) after verifying the magic code in this flow. The current implementation always navigates to SETTINGS_NEW_CONTACT_METHOD, so even when the effect runs, the user does not see the contact methods list.

2. Timing when coming back online: When the user goes offline, then pastes the code and goes back online (troubleshoot modal dismisses), the Verify request may be sent after reconnection. Write requests are processed through the sequential queue, and success/failure Onyx updates for writes are applied via queueOnyxUpdates and flushed after the queue processes. If the troubleshoot modal’s dismissal changes the navigation stack or focus, or if the component re-renders in a way that doesn’t see the updated isVerifiedValidateActionCode in time, the navigation that should run in the useEffect might not execute or might not complete as expected. So the redirect can also fail to occur at all when verification completes right after coming back online.

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

Change 1: Redirect to the contact methods list after verification

In NewContactMethodConfirmMagicCodePage.tsx, after successful verification of the magic code (when isVerifiedValidateActionCode is true), navigate to the contact methods list instead of the new contact method form.

Current code (wrong destination):

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

Lines 26 to 31 in 6e6fec5

	useEffect(() => {
	if (!pendingContactAction?.isVerifiedValidateActionCode) {
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_NEW_CONTACT_METHOD.getRoute(navigateBackTo));
	}, [navigateBackTo, pendingContactAction?.isVerifiedValidateActionCode]);

Proposed code (redirect to contact methods list):

useEffect(() => {
    if (!pendingContactAction?.isVerifiedValidateActionCode) {
        return;
    }
    Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(navigateBackTo));
}, [navigateBackTo, pendingContactAction?.isVerifiedValidateActionCode]);

This aligns the post-verification destination with the expected result: user is redirected to the contact methods list.

Change 2 (if redirect still does not run after going online): Ensure navigation runs when verification completes

If testing shows that the redirect still does not happen when verification completes immediately after going back online (e.g. because of update ordering or modal dismissal), we can make the navigation more reliable by:

• Using InteractionManager.runAfterInteractions so navigation runs after the troubleshoot modal and any transitions have finished, or
• Ensuring the effect runs when isVerifiedValidateActionCode transitions to true by keeping the dependency as-is and, if needed, adding a short delay or running navigation in a requestAnimationFrame so it is not lost during stack updates when the modal dismisses.

Implementation of Change 2 should be done only if Change 1 alone does not fix the “no redirect” case after going online; the exact approach can be chosen after verifying behavior on staging.

What alternative solutions did you explore? (Optional)

• Keeping redirect to SETTINGS_NEW_CONTACT_METHOD: That would leave the current “wrong destination” behavior and does not match the expected result (contact methods list).
• Only fixing timing (Change 2) without changing destination: That would not satisfy the requirement to redirect to the contact methods list; the user would still land on the new contact method form instead of the list.
• Navigating to SETTINGS_CONTACT_METHODS only when the user was offline during the step: That would add branching and state (e.g. “was offline when modal closed”) and is more complex; aligning the post-verification destination to the contact methods list for this screen is simpler and matches the stated expected result.

[MobileMage]

Proposal

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

When a user adds a secondary contact method and verifies the magic code while offline, going back online does not redirect the user to the contact methods list. Instead, the user remains on the verification page and must manually navigate back.

What is the root cause of that problem?

In NewContactMethodConfirmMagicCodePage.tsx at line 30, after the secondary login code is verified successfully (when isVerifiedValidateActionCode becomes true), the useEffect navigates to ROUTES.SETTINGS_NEW_CONTACT_METHOD which is the form to add a new contact method. However, the expected behavior is to redirect to the contact methods list page (ROUTES.SETTINGS_CONTACT_METHODS), which is where the user started from and should return to after completion.

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

Change the navigation route in the useEffect to redirect to the contact methods list instead of the new contact method form:

--- a/src/pages/settings/Profile/Contacts/NewContactMethodConfirmMagicCodePage.tsx
+++ b/src/pages/settings/Profile/Contacts/NewContactMethodConfirmMagicCodePage.tsx
@@ -27,7 +27,7 @@ function NewContactMethodConfirmMagicCodePage({route}: NewContactMethodConfirmM
         if (!pendingContactAction?.isVerifiedValidateActionCode) {
             return;
         }
-        Navigation.navigate(ROUTES.SETTINGS_NEW_CONTACT_METHOD.getRoute(navigateBackTo));
+        Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHODS.getRoute(navigateBackTo));
     }, [navigateBackTo, pendingContactAction?.isVerifiedValidateActionCode]);

What alternative solutions did you explore? (Optional)

An alternative would be to navigate back instead of forward using Navigation.goBack(), which is what the onClose handler already does. However, using Navigation.navigate() with the correct destination route is more reliable and consistent with the application's navigation patterns.

[github-actions]

⚠️ @twinkle-react Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.