Profile - Address - Zip code verification does not work correctly

[lanitochka17]

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

---

Version Number: 1.4.70-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4537799
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Open app or go to staging.new.expensify.com
2. Login with any account that does not have an address in Profile
3. Go to Settings > Profile > Address
4. Enter any US address with a numeric-only zip code and save it
5. Open address again and input any UK address with a zip code containing letters and numbers and save it
6. Do the same on the new account but first add the address in UK

Expected Result:

User can replace the saved address with numeric zip code with address with letters-numeric zip code and vice versa

Actual Result:

Zip code verification does not work correctly
User can NOT replace the saved address with numeric zip code with address with letters-numeric zip code and vice versa

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6469247_1714675718994.profile-address-zip-code-verification-fail.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[lanitochka17]

@srikarparsi FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[srikarparsi]

This looks like it could be associated with this PR: https://github.com/Expensify/App/pull/38381/files. Looking into it.

[srikarparsi]

Not able to reproduce on the latest dev. Still looking. Could be a backend problem since I haven't built in a day.

[srikarparsi]

profileAddress.mov

Not able to reproduce with a new account. Building auth right now and will test with that. If it doesn't work then it's a backend problem, if it does work, then a recent frontend change might've fixed it and I can try finding that?

[francoisl]

I'm able to repro on main – I had to rerun npm i, maybe you were missing that? Not 100% sure yet, but I think the issue comes from #41056 that bumped the onyx-react-native version (which would also explain why you couldn't repro without running npm i)

[francoisl]

Did some more digging, reverting react-native-onyx to 2.0.32 fixes the issue, and it starts appearing in 2.0.33, which means it would have been introduced via (or as a side effect of) Expensify/react-native-onyx#519.

2.0.32	2.0.33
r2032.mov	r2033.mov

cc @chrispader @tgolen if you have an idea

What's happening is that the country key doesn't get updated on the Address page, so we end up using the wrong validation regex for the zip code when you try to save the changes.

[chrispader]

Fixed in #42057

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

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

• Bump Onyx to 2.0.41 #42057

If no regressions arise, payment will be issued on 2024-06-05. 🎊

[melvin-bot]

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

• Bump Onyx to 2.0.41 #42057

If no regressions arise, payment will be issued on 2024-06-06. 🎊

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[ikevin127]

⚠️ Automation failed here -> this should be on [HOLD for Payment 2024-06-21] according to yesterday’s production deploy of the 2nd PR (after revert) from #42772 (comment).

Additional issue attached to the PR Fixed Issues section:

• [HOLD for payment 2024-07-10] [HOLD for payment 2024-07-02] [$250] [HOLD for Payment 2024-06-21] LOW: [Performance] Improve the performance of getCachedCollection #41895

@srikarparsi Could you please remove the previous HOLD from the issue's title and add the correct one and also add the Bug label to get a BZ team member assigned in order to handle payment here when it's due ?

cc @mountiny

1. This onyx bump was a big PR which took lots of testing and given this, would you be cool with a $500 bounty for the C+ reviewers given the work involved in both reverted and currently merged PR ?
2. What are we going to do about current / possible regressions (if any) in the context of the bounty ? Asking if any existing regression will -50% the bounty or not.

[melvin-bot]

Triggered auto assignment to @OfstadC (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.

[ikevin127]

Based on this #expensify-open-source Slack discussion Vit suggested to handle payment in issue:

• [HOLD for payment 2024-07-10] [HOLD for payment 2024-07-02] [$250] [HOLD for Payment 2024-06-21] LOW: [Performance] Improve the performance of getCachedCollection #41895

Edit:

Confirmed by Vit in:

• [HOLD for payment 2024-07-10] [HOLD for payment 2024-07-02] [$250] [HOLD for Payment 2024-06-21] LOW: [Performance] Improve the performance of getCachedCollection #41895 (comment)

Therefore this can be checked-off as completed, thank you all !

cc @OfstadC @srikarparsi