[$250] Account - secondary contact method isn't auto assigned as the default contact method

[vincdargento]

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.39-1
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://github.com/Expensify/Expensify/issues/423514
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team

Action Performed:

1. Login as a new user with a new email address and complete the onboarding process
2. Navigate to account -> Profile -> Contact Methods
3. Add a secondary contact method and validate it
4. Close the contact method page and open it again

Expected Result:

The secondary contact method isn't auto assigned as the default contact method

Actual Result:

The contact method is still assigned as the original account

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abdulrahuman5196

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022033942371331862316
• Upwork Job ID: 2033942371331862316
• Last Price Increase: 2026-04-14

[MelvinBot]

Proposal

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

After a new user adds a secondary contact method and validates it, then closes and reopens the Contact Methods page, the secondary contact method appears to be auto-assigned as the default contact method — even though the user never explicitly set it as the default.

What is the root cause of that problem?

The ContactMethodsPage determines the "default" contact method by comparing each login's partnerUserID against session.email (ContactMethodsPage.tsx:41). The entry matching session.email is sorted to the top and labeled "We'll use this method to contact you" (UserUtils.ts:135-146).

The client-side validateSecondaryLogin() function (User.ts:507-597) only sets validatedDate on the login entry and validated: true on the account in its optimistic/success data — it does not update session.email or account.primaryLogin. The only client-side function that explicitly changes session.email is setContactMethodAsDefault() (User.ts:1050+), which requires a deliberate user action.

However, the server response from the ValidateSecondaryLogin API command can include additional Onyx updates beyond what the client specifies. If the server returns an update that changes ONYXKEYS.SESSION.email to the newly validated contact method (which is plausible for new users whose original signup email may not yet be formally set as the primary login), then on the next render the ContactMethodsPage would show the secondary contact method as the default.

This explains why the issue manifests after "closing and reopening" the page — the server response arrives and updates session.email, and when the page is revisited it re-reads the updated session data.

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

This requires investigation of the backend ValidateSecondaryLogin command handler to confirm whether the server response includes an Onyx update that changes session.email or the primary login for new users. Once confirmed:

Option A (Backend fix — preferred): Ensure the ValidateSecondaryLogin backend command does not change the user's primary login / session.email as a side effect of validation. Validating a secondary login should only set the validatedDate on that login, not promote it to primary/default.

Option B (Client-side guard): If the backend behavior is intentional for some reason, the client could preserve the current default when processing the server response from ValidateSecondaryLogin. For example, in the success callback, explicitly re-merge the original session.email to prevent the server from overwriting it.

What alternative solutions did you explore? (Optional)

• Checked whether sorting logic in getContactMethodsOptions() (UserUtils.ts:135) could promote newly validated methods — it cannot, since it only checks against session.email.
• Checked whether account.primaryLogin is used on the ContactMethodsPage — it is not; the page uses session.email directly.
• Verified that setContactMethodAsDefault is never called automatically after validation — it requires explicit user action via a menu item on the ContactMethodDetailsPage.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[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/~022033942371331862316

[surafeal-dev]

Proposal

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

• After a user validates a newly added secondary contact method and then closes and reopens the Contact Methods page, the newly validated secondary method may appear as the default contact method even though the user never explicitly set it as default.

What is the root cause of that problem?

• The UI determines the default contact method by comparing each login against session.email. The client validateSecondaryLogin() only marks the login validated locally, but the server-side ValidateSecondaryLogin command can return Onyx updates that modify session.email or the account primary login. If the server response sets session.email to the newly validated method (for example, in certain new-user flows), subsequent renders will treat that method as the default. This is why the issue appears after closing and reopening the page—server-sent Onyx updates arrive and persist between navigations.

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

• Preferred (backend) fix:
  • Update the ValidateSecondaryLogin server handler to stop changing the user’s primary login / session.email as a side effect of validation. Validation should only set validatedDate on the login entry and not promote it to primary/default.
• Client-side guard (if backend change is not immediately possible):
  • When processing the success response for validateSecondaryLogin(), preserve the existing session.email (reapply it after merging server-sent Onyx updates) so the server cannot silently change the default without explicit user action.
• UX defensive measure (optional):
  • Make the UI explicitly show a “Recently validated” state for newly validated methods and only mark a method as default when setContactMethodAsDefault() has been intentionally invoked by the user.

What alternative solutions did you explore? (Optional)

• Change sorting logic to ignore session.email — rejected because it would hide the symptom rather than address the source of truth.
• Auto-promote validated methods client-side — rejected because it would break explicit user control and could unexpectedly change preferences.

Testing and verification

• Inspect server ValidateSecondaryLogin handler to confirm whether it writes session.email/primary login.
• Manual QA:
  1. Add and validate a secondary contact method.
  2. Close and reopen Contact Methods page.
  3. Confirm the previously-default method remains the default unless the user explicitly set a new default.
• Automated tests:
  • Unit test for validateSecondaryLogin() merge behavior to ensure session.email is preserved.
  • Integration test that simulates a server response attempting to change session.email and verifies the client-side guard (if implemented).

Next steps

• Prefer backend change: ask backend team to remove any session.email promotion from ValidateSecondaryLogin.
• If backend cannot change immediately: implement the client-side guard and add tests.

[jainam884]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @jainam884 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.

[mnshrm]

@vincdargento,
I went through the steps and attached video as well, just wanted to confirm if the expected result is secondary contact shouldn't be added as the default one OR the secondary contact should be added as the default one, reason for this question is the behavior in video, after adding secondary contact (with '+2'), it wasn't set as the default one, it was still the original contact (with '+1'), this behavior according to reproduction steps follows the expected result that secondary contact shouldn't be set as the default one. So, not sure how this is a bug, may be the expected result part of the description needs to be updated.

[melvin-bot]

📣 @mnshrm! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[mnshrm]

Contributor details
Your Expensify account email: asysnsrs665@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01dd0bcc8a7e29b961