[HOLD for payment 2023-04-12] [$2000] City and State doesn’t populate for the address I-80 but works well with other address like I-35 , I-40, I-70

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open chrome staging dot
2. Go to personal information and address
3. In the address field type in : I
4. Try to select I-80 and see that the city and state doesn't populate with the recommended address
5. But if you select I-35, I-40 or I-70, every recommended address like city , state, and country populates without a problem

Expected Result:

Setting address I-80 (Interstate 80) should populate the addresses as per the recommendation

Actual Result:

Setting address I-80 (Interstate 80) doesn’t populate the addresses as per the recommendation

Workaround:

unknown

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.2.80-1
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:

address.mp4

Recording.1650.mp4

Expensify/Expensify Issue URL:
Issue reported by: @priya-zha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1678254121686449

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0195f9f8aaab8dc5c1
• Upwork Job ID: 1634338652687765504
• Last Price Increase: 2023-03-17

[MelvinBot]

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

[arielgreen]

Note that even for other ones (e.g., I-35), it doesn't populate zip.

[MelvinBot]

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

[MelvinBot]

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

[MelvinBot]

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

[MelvinBot]

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

[sshere]

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

The users address is not populating when you use the auto-completion from Google.

What is the root cause of that problem?

The root cause of this is due to the backend server not returning an address. This is not an issue with the frontend application.

[MelvinBot]

📣 @sshere! 📣

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. 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.
2. 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.
3. 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>

[sshere]

Contributor details
Your Expensify account email: sshere1985@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0116ef5450a33cc027

[MelvinBot]

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

[tienifr]

Proposal

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

Setting address I-80 (Interstate 80) doesn’t populate the addresses (city, state, ...) as per the Google Places Autocomplete

What is the root cause of that problem?

The root cause is:

1. When we fetch the data from the Google Places Autocomplete, it tries to give us predictions on the places even though the places might not exist in Google's database
2. When clicking on the place in the autocomplete list, we retrieve the place details from the Google Place API, which will only return the address that exists Google's database
3. The autocomplete option for 'I-80' query does not exist in Google's database, so when we get its details, Google will try to find the closest address in its database and return it, in this case the address in Google's database does not have information like city, state, ...

For more information please refer to Google's response here: https://issuetracker.google.com/issues/35823492#comment2
This is a known behavior.

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

To fix this, we need to use the Google's place autocomplete information as a fallback in case the Place Detail does not have that information.
For example, when we query for I 80 and click on the I-80, Seward, NE, USA result in the autocomplete dropdown.
If we don't have the state from the Place Detail API, we'll use NE from the autocomplete result as a fallback.
If we don't have the city from the Place Detail API, we'll use Seward from the autocomplete result as a fallback.

The response from Google Autocomplete is quite structured so we can retrieve the state and city using the following logic:

const fallbackData = autocompleteData.terms;
const stateAutocompleteFallback = fallbackData.length >= 2 ? fallbackData[fallbackData.length - 2].value : '';
const cityAutocompleteFallback = fallbackData.length >= 3 ? fallbackData[fallbackData.length - 3].value : '';

in

App/src/components/AddressSearch.js

Line 85 in 4a172c9

const saveLocationDetails = (details) => {

The autocompleteData can be passed into saveLocationDetails by using the data returned in

App/src/components/AddressSearch.js

Line 157 in 4a172c9

onPress={(data, details) => {

.

There might we wild result format returned from Google Autocomplete for countries other than the US, if we're not sure we can limit the above fallback logic to addresses in the US. It will improve the user experience.

What alternative solutions did you explore? (Optional)

NA

Result

Working well after the fix:

Screen.Recording.2023-03-11.at.12.40.30.mov

[sobitneupane]

Thanks for the proposal @tienifr.

But I don't think we can go with your proposal because it depends on the structure of data returned from an api which is not always consistent.

[tienifr]

@sobitneupane sure, the structure of the address within the US is very consistent as I observed.

I agree my solution will be the last one to be considered if there's no other perfect solution.

[francoisl]

I'd be ok with this solution, though it sounds like it wouldn't work very well for all non-US addresses. Looking at the terms array for random addresses from other countries, the city is not always at index fallbackData.length - 3, and the state is not always at index fallbackData.length - 2, because other countries don't necessarily use the same <street number> <street name> <city> <state> address format.

Alternatively, we could use this fallback solution only if the predicted country is USA?

[tienifr]

Alternatively, we could use this fallback solution only if the predicted country is USA?

@francoisl yes we can do this as well.

[MelvinBot]

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

[MelvinBot]

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

• fix/15753: suggested address not populate if unknown to google db #16388

If no regressions arise, payment will be issued on 2023-04-12. 🎊

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 @priya-zha
• Contributor that fixed the issue @tienifr
• Contributor+ that helped on the issue and/or PR @sobitneupane

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

[MelvinBot]

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:

• [@sobitneupane / @francoisl] The PR that introduced the bug has been identified. Link to the PR: This was an edge case that wasn't taken into consideration in the original PR that added address autocomplete functionality
• [@sobitneupane / @francoisl] 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: N/A
• [@sobitneupane / @francoisl] 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: N/A
• [@arielgreen] Determine if we should create a regression test for this bug. Yes
• [@sobitneupane] 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. - see this comment
• [@arielgreen] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: https://github.com/Expensify/Expensify/issues/278265

[francoisl]

I filled out most of the checklist above. For the regression test steps, we can use this comment @arielgreen.

[arielgreen]

@tienifr @sobitneupane @priya-zha, please apply for this posting on Upwork asap so I can send payment

[tienifr]

@arielgreen I’ve applied, thanks!

[priya-zha]

@arielgreen Submitted the proposal. Thanks

[sobitneupane]

@arielgreen Proposal Submitted.

[francoisl]

@arielgreen are we all set here with payments and the regression steps issue?

[MelvinBot]

@francoisl, @sobitneupane, @arielgreen, @tienifr Whoops! This issue is 2 days overdue. Let's get this updated quick!

[francoisl]

@arielgreen friendly bump ^

[arielgreen]

@priya-zha @tienifr paid, apologies for delay

[arielgreen]

Just waiting on @sobitneupane to accept, then everything here is done and we can close.

[sobitneupane]

@arielgreen Accepted the offer.

[arielgreen]

All payments made, we are set here.