[HOLD for payment 2023-05-16] [$1000] Duplicate phone numbers are accepted as a contact method

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Go to "Contact method"
2. Click on "New contact method"
3. Enter a phone number
4. Click "Add"
5. Click on "New contact method" again
6. Enter the same phone number as before
7. Click "Add"

Expected result:

The duplicate contact method added should not be shown, and no error should be shown.

Actual result:

Two contact methods with the same phone number are being shown and both have errors.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.8.8
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

2023-04-29.15.54.08.mp4

Expensify/Expensify Issue URL:
Issue reported by: @Nathan-Mulugeta
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1682773410951039

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~014cd7afa4b6e6e6d5
• Upwork Job ID: 1652877111573905408
• Last Price Increase: 2023-05-01

[MelvinBot]

Triggered auto assignment to @kadiealexander (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[MelvinBot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[PrashantMangukiya]

Proposal

Posting proposal early as per new guidelines

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

Duplicate phone numbers are accepted as a contact method

What is the root cause of that problem?

Whenever new contact method added it will call submitForm function as shown below:

App/src/pages/settings/Profile/Contacts/NewContactMethodPage.js

Lines 77 to 84 in a786349

	const submitForm = useCallback(() => {
	// If this login already exists, just go back.
	if (lodashGet(props.loginList, login)) {
	Navigation.navigate(ROUTES.SETTINGS_CONTACT_METHODS);
	return;
	}
	User.addNewContactMethodAndNavigate(login, password);
	}, [login, props.loginList, password]);

We are using lodashGet(props.loginList, login) to check that login already exist within login list or not. So here when we enter phone number in different format at that time key within props.loginList become different so it will not able to detect that phone number already exist within login list. This is the root cause of the problem.

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

Within submitForm() function we have to use LoginUtils.getPhoneNumberWithoutSpecialChars() function and then we have to use it within lodashGet() to check that login key already exist within props.loginList or not. Updated code for submitForm() is as shown below.

const submitForm = useCallback(() => {
    const phoneLogin = LoginUtils.getPhoneNumberWithoutSpecialChars(login); // *** Add this ***

    // If this login already exists, just go back.
    if (lodashGet(props.loginList, phoneLogin))  {  // *** Updated Code
     ....
    }
    ....
}, [login, props.loginList, password]);

This will solve the issue i.e. do not allow to enter same phone number although in different format as shown in result video.

What alternative solutions did you explore? (Optional)

None

Results

18207-DuplicatePhoneNumber.mp4

[Prince-Mendiratta]

I think this issue will be resolved by #18103

cc @s77rt

[s77rt]

Thanks @Prince-Mendiratta. Indeed it shall be fixed by that PR.

[kadiealexander]

Reproduced in desktop app version 1.3.8-8.

[MelvinBot]

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

[MelvinBot]

Current assignee @kadiealexander is eligible for the External assigner, not assigning anyone new.

[MelvinBot]

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

[MelvinBot]

Triggered auto assignment to @techievivek (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[kadiealexander]

Oops, I just read #18207 (comment). I'll place this on hold until #18103 is done.

[kadiealexander]

#18103 has been deployed to staging and my staging version of Expensify appears to have this fixed:

2023-05-04_16-23-09.mp4

Closing this now as the issue is resolved. Please reopen if it pops up again!

[Nathan-Mulugeta]

@kadiealexander I have tried to retest this issue on the latest version on Staging, I am still able to repro this bug. Take a look at this video:

2023-05-04.07.54.56.mp4

I have tested on this staging version:

[kadiealexander]

I tested this on the staging web app in Chrome just to be sure and I'm still unable to reproduce it:

2023-05-04_17-03-13.mp4

[Nathan-Mulugeta]

Hello @kadiealexander, I have identified two factors that can reproduce the bug. Firstly, please ensure that the phone number you use is not already registered as a contact method in another account or doesn't already generate any error. Use a new phone number to avoid any conflicts. I have tried to use a phone number that is already registered and as you can see on the video the bug can't be seen when doing that.

Secondly, if you repeatedly add invalid phone numbers, the app will throttle the user and block any new numbers. To avoid this, please log in to a new account or use another account that hasn't been testing this repeatedly. By using a new phone number and an account that hasn't been throttled, you can reproduce the bug accurately.

2023-05-04.08.22.59.mp4

[kadiealexander]

Thank you for sharing those factors, I was able to reproduce the bug using a brand new number:

2023-05-04_17-51-00.mp4

[s77rt]

@PrashantMangukiya Thanks for the proposal and sorry that I missed it. I should have reviewed this first. I think your proposal is outdated and the RCA is not valid (at least not anymore).

[PrashantMangukiya]

@PrashantMangukiya Thanks for the proposal and sorry that I missed it. I should have reviewed this first. I think your proposal is outdated and the RCA is not valid (at least not anymore).

@s77rt It's ok. Thank you.

[Prince-Mendiratta]

@s77rt

Can you please check where this is originating from?

We are saving optimistic data using just the contact number without SMS domain. When the requests have been throttled and the user tries to enter a contact number, a new entry is made in the loginList with just the contact number as well as a new update is received from the API that is with the SMS domain. This leads to both variants existing in the loginList and thus, the user is not able to add the number twice.

This does not happen when the requests have not been throttled though. In this scenario, the optimistic data adds the contact number without SMS domain to loginList and after update is received from API with SMS domain, the contact number without SMS domain is removed from the loginList and we are able to add the same contact again.

This issue should be fixed by using the contact with SMS login for addNewContactMethodAndNavigate method as well altogether. So we just need to change the statement to const userLogin = parsedPhoneNumber.possible ? (parsedPhoneNumber.number.e164 + CONST.SMS.DOMAIN) : login; not just for the comparison, but for saving the user details in API as well.

[s77rt]

@Prince-Mendiratta Thanks for the quick response, but will the api accept a phone number with sms domain as a valid input?

[Prince-Mendiratta]

@s77rt Yes, I already tested it in the various scenarios and it works perfectly.

[s77rt]

@Prince-Mendiratta Awesome! Let's just use addSMSDomainIfPhoneNumber then.

🎀 👀 🎀 C+ reviewed

cc @techievivek

[Prince-Mendiratta]

@s77rt Also, I'm not 100% sure but this fix should resolve these issues as well since the RCA looks same:

• [$1000] Error Adding Valid Email as Contact Method After Removing Invalid Email #17898
• Inconsistent error handling between Sign in page and Contact methods page #18116

[s77rt]

@Prince-Mendiratta I didn't check the RCA of those issues as they seem related to "email" and not phone numbers? But it would be great if we can get more issues fixed with one PR.

[melvin-bot]

📣 @Prince-Mendiratta You have been assigned to this job by @techievivek!
Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[Prince-Mendiratta]

PR is up for review!

cc @s77rt @techievivek

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.12-0 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [NewContactPage] fix: same number added twice #18536

If no regressions arise, payment will be issued on 2023-05-16. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@s77rt] The PR that introduced the bug has been identified. Link to the PR:
• [@s77rt] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@s77rt] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@s77rt] Determine if we should create a regression test for this bug.
• [@s77rt] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@kadiealexander] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[s77rt]

• The PR that introduced the bug has been identified: The bug existed since day one: New contact method #15330
• The offending PR has been commented on: New contact method #15330 (comment)
• A discussion in #expensify-bugs has been started: https://expensify.slack.com/archives/C049HHMV9SM/p1683643048701839
• Determine if we should create a regression test for this bug: I don't have a strong feeling that this deserves a regression test, so no.

[Prince-Mendiratta]

Sharing the timeline of this issue to help with the eventual analysis, calculated with this tool.

🐛 Issue created at: Sun, 30 Apr 2023 04:35:40 GMT
🧯 Help Wanted at: Mon, 01 May 2023 03:26:46 GMT
🕵🏻 Contributor assigned at: Fri, 05 May 2023 17:27:46 GMT
🛸 PR created at: Sun, 07 May 2023 11:19:57 GMT
🎯 PR merged at: Mon, 08 May 2023 07:45:23 GMT
⌛ Business Days Elapsed between assignment and PR merge: 1

[kadiealexander]

Sent contracts to @Prince-Mendiratta, @s77rt and @Nathan-Mulugeta, please let me know once they've been accepted and I'll pay!

[Nathan-Mulugeta]

Thanks @kadiealexander , received.

[s77rt]

@kadiealexander Accepted!

[kadiealexander]

Everyone is paid!