[$250] Contact method - App logs out when deleting unverified contact method

[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.38-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/folder/13176687/test-cases/49419429
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11 pro /Chrome
App Component: User Settings

Action Performed:

1. Navigate to staging.new.expensify.com
2. Click on Account.
3. Click on Profile.
4. Click on Contact Methods.
5. Click on New Contact Method.
6. Enter a valid email and click Add. Don't verify the newly added account
7. On the Contact Methods screen, click the recently added unverified contact method.
8. Click the three-dot menu in the header.
9. Click Remove.
10. Click Yes, Continue.

Expected Result:

User is redirected to the Contact Methods page, and the unverified contact method is no longer listed.

Actual Result:

The App logout completely.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7104584_1773692341254.bandicam_2026-03-16_23-11-15-783.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dukenv0307

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022033654018749901012
• Upwork Job ID: 2033654018749901012
• Last Price Increase: 2026-03-24

[MelvinBot]

Proposal

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

When a user adds a new contact method (email), does not verify it, and then removes it via the three-dot menu → Remove → Yes, Continue, the app logs out completely instead of navigating back to the Contact Methods page.

What is the root cause of that problem?

The deleteContactMethod function in src/libs/actions/User.ts:227-277 only modifies ONYXKEYS.LOGIN_LIST — it never touches SESSION, ACCOUNT, or CREDENTIALS. There are also no client-side Onyx subscribers on LOGIN_LIST that trigger a logout when a login entry changes. This means the logout must originate from the server response to the DeleteContactMethod API call.

The most likely path is:

1. The server returns a 407 (NOT_AUTHENTICATED) response to DeleteContactMethod when the contact method is unverified
2. The Reauthentication middleware (src/libs/Middleware/Reauthentication.ts:63-96) detects the 407 and attempts to reauthenticate
3. If reauthentication fails (e.g. because the server invalidated the credentials as part of the delete operation), redirectToSignIn() is called (src/libs/Authentication.ts:189-194)
4. redirectToSignIn calls Onyx.clear() which wipes the SESSION including authToken (src/libs/actions/SignInRedirect.ts:47-117)
5. useIsAuthenticated returns false → app shows the sign-in screen

Notably, the Reauthentication middleware has a comment at line 69-71 stating that "creating and deleting logins" should NOT be retried on 407, but the actual implementation doesn't enforce this for write commands — DeleteContactMethod gets shouldRetry=true and apiRequestType='write' automatically, so the skip condition at line 79 ((!shouldRetry && !apiRequestType)) is always false, and reauthentication always proceeds.

An alternative (but less likely) path is that the server includes onyxData in the DeleteContactMethod response that directly clears or modifies the SESSION key.

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

Pass skipReauthentication: true in the request data for DeleteContactMethod so that when a 407 is received, the Reauthentication middleware skips the reauthentication attempt and returns the raw response. This allows the client's failureData to be applied (restoring the login entry with an error message) rather than triggering the redirectToSignIn → Onyx.clear() chain that logs the user out.

The change would be in src/libs/actions/User.ts inside deleteContactMethod, adding skipReauthentication: true to the command parameters or request data.

Additionally, the server-side DeleteContactMethod command should be investigated to understand why it returns a response that invalidates the session for unverified logins specifically.

What alternative solutions did you explore? (Optional)

1. Modify the Reauthentication middleware to handle login-related commands differently (matching the intent of the comment at line 69-71). This would be a broader fix affecting all login create/delete commands but is harder to scope correctly.
2. Server-side fix only — fix the server's DeleteContactMethod to not return 407 or session-clearing onyxData for unverified logins. This addresses the root cause but leaves the client unprotected against similar server responses.

The recommended approach (client-side skipReauthentication) is the most targeted fix and aligns with the existing pattern used by SignInWithShortLivedAuthToken.

---

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 - @dukenv0307 (External)

[melvin-bot]

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

[shivang-goliyan]

Proposal

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

When a user adds a new contact method, skips verification, and then deletes it via the three-dot menu → Remove → Yes, Continue, the app logs them out entirely instead of navigating back to the Contact Methods page.

What is the root cause of that problem?

The deleteContactMethod() function in User.ts:273-275 calls API.write(DELETE_CONTACT_METHOD) without setting skipReauthentication: true. For all WRITE commands, prepareRequest() in API/index.ts:113-116 auto-sets shouldRetry: true and apiRequestType: 'write'.

When the server responds with a 407 (NOT_AUTHENTICATED) — likely because deleting an unverified login triggers a security check — the Reauthentication middleware at Reauthentication.ts:63 catches it. The skip condition at line 79 evaluates (!shouldRetry && !apiRequestType) || skipReauthentication, which resolves to (!true && !'write') || undefined → false. So reauthentication proceeds instead of being skipped.

After exhausting retries, retryReauthenticate() calls redirectToSignIn() at line 39, which calls Onyx.clear(), wipes SESSION.authToken, and the app drops to the sign-in screen.

The ironic part: lines 69-71 of Reauthentication.ts have a comment that says "creating and deleting logins" should NOT be retried on auth failure. But the implementation doesn't enforce this for WRITE commands unless skipReauthentication is explicitly passed — which DeleteContactMethod never does.

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

Add skipReauthentication?: boolean to DeleteContactMethodParams in src/libs/API/parameters/DeleteContactMethodParams.ts, and pass skipReauthentication: true in the parameters object at User.ts:273.

This makes the middleware return the raw 407 response without attempting reauthentication. The response flows through SaveResponseInOnyx, which applies failureData — restoring the login entry with an error message. User stays logged in.

This follows the same pattern already used by LogOut (Session/index.ts:242) and SignInWithShortLivedAuthToken (Session/index.ts:783).

Worth noting: addNewContactMethod() at User.ts:360-443 has the same vulnerability — it's also a WRITE command without skipReauthentication, and the comment at line 69-71 calls out both "creating AND deleting logins." That could be addressed in the same PR.

What alternative solutions did you explore? (Optional)

I considered modifying the Reauthentication middleware itself to maintain a list of commands that should skip reauthentication (DeleteContactMethod, AddNewContactMethod, etc). This works but couples the middleware to specific command names and needs updating whenever a new login-related command is added. The skipReauthentication flag is more composable — each command opts in independently.

A server-side-only fix (preventing the 407 for unverified login deletion) would address the root cause but leaves the client unprotected, and the middleware comment explicitly says this should be handled client-side.

[shengxinzhe]

Proposal

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

When a user adds a new contact method (email), does not verify it, and then removes it via the three-dot menu → Remove → "Yes, Continue", the app logs out completely instead of navigating back to the Contact Methods page.

What is the root cause of that problem?

There is a race condition between the optimistic deletion update and a useEffect hook in ContactMethodDetailsPage.tsx.

Step-by-step flow of the bug:

1. User clicks "Remove" → deleteContactMethod() is called (User.ts:227).

2. The optimistic update sets partnerUserID: '' on the login entry (User.ts:236), along with pendingFields.deletedLogin: DELETE.

3. Navigation.goBack() is called immediately (User.ts:276), but the page component is still mounted during the navigation transition.

4. The useEffect at ContactMethodDetailsPage.tsx:179-186 fires because loginData.partnerUserID changed (it's in the dependency array). The guard condition !loginData?.partnerUserID now evaluates to true (because '' is falsy), but it returns early instead of proceeding — so the useEffect itself isn't the direct trigger.

5. The actual trigger: when partnerUserID is set to '' optimistically, any Onyx subscriber that computes the current user's identity from LOGIN_LIST sees the primary login's partnerUserID become empty. The Reauthentication middleware (Reauthentication.ts:78-79) handles any 407 response from the DELETE_CONTACT_METHOD API call. Since the call doesn't set shouldRetry: false, a 407 triggers re-authentication which calls redirectToSignIn() (Reauthentication.ts:39), logging the user out.

The core issue is that deleteContactMethod does not pass shouldRetry: false for the API write, so the reauthentication middleware can redirect to sign-in on any transient auth error during the delete operation.

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

1. In src/libs/actions/User.ts (deleteContactMethod): Add the isRetryAllowed: false parameter to the API.write() call to prevent the reauthentication middleware from triggering a redirect to sign-in during the deletion.

2. In src/pages/settings/Profile/Contacts/ContactMethodDetailsPage.tsx: Add a check for loginData?.pendingFields?.deletedLogin to the useEffect guard at line 181, so it doesn't attempt to run resetContactMethodValidateCodeSentState() when a deletion is already in progress:

   if (!loginData?.partnerUserID || loginData?.validatedDate || prevPendingDeletedLogin || loginData?.pendingFields?.deletedLogin) {
       return;
   }

This two-part fix addresses both the reauthentication issue and the stale state update race condition.

What alternative solutions did you explore? (Optional)

An alternative would be to change the optimistic data to not clear partnerUserID (keeping the original value during the pending delete), but this could cause other visual inconsistencies if the component renders with stale data during the optimistic period.

Upwork profile: https://www.upwork.com/freelancers/~01e5a8f9c2b4d6a730

[melvin-bot]

📣 @shengxinzhe! 📣
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>

[shengxinzhe]

Contributor details
Your Expensify account email: shengyu_0830@163.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0173a64078113c2de8

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!