App: [N6] Wrong value in AddressSearch after refresh

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. Create NewDot account, verify it, log in
  2. Create Workspace
  3. Do the add Bank account step (first step) of VBA flow (use this SO)
  4. You should be in Company Step
  5. Type something in the Company Address field, choose an address result
  6. Type something in another field
  7. Refresh the page

Expected Result:

The Company Address field should have the value we input before refresh

Actual Result:

The Company Address doesn’t have the right value:

https://user-images.githubusercontent.com/87341702/137230266-e6c60a2c-34f4-47b6-9e45-7b50b1b91a72.mov

Workaround:

The user can input the address again

Platform:

Where is this issue occurring?

  • Web
  • iOS
  • Android
  • Desktop App
  • Mobile Web

Version Number: Reproducible in staging?: Reproducible in production?: Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation Expensify/Expensify Issue URL: Issue reported by: Slack conversation:

View all open jobs on GitHub

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 34 (33 by maintainers)

Most upvoted comments

I’ve got a potential fix I want to try

It might not be a perfect solution, but it will be an improvement from what we have currently. We can address issues with other addresses as they come up. I think we should maybe also add some unit test coverage of the saveLocationDetails function to help maintain it in the future.

Well, it actually seems to work if we add types: ‘address’ in the query object

Good find! Feel free to submit a PR!

Well, it actually seems to work if we add types: 'address' in the query object

If you input 88 Kearny Street you get the full address result and not the premise with missing data.

Do you want me to submit a PR?

I’m not sure I understand this suggestion. I’m suggesting that if a user attempts to select an address from the GooglePlacesAutocomplete component with this properties, then we know that it’s an invalid address for our purposes, and we’ll display an error in the form.

My suggestion was toward filtering out bad results in our backend so the user never see them, but it is not so easy as I thought.

I’ll implement the validations you suggested in the front, or if you want, you can implement them, what do you prefer?

Okay, here’s what I suggest we do:

  1. Include type: address in the query.
  2. Validate that one of the address_components has a types array that contains street_number
  3. Validate that none of the address_components has a types array that contains post_box

That sounds good to me, but I would suggest doing (2) and (3) as filters in our backend so we don’t show those results to the user. I think it is better experience than showing results that eventually will lead to validation errors. What do you think about that? scratch that, we can’t do that there because we don’t have that information at that time (autocomplete query)

Okay, I just found this SO which appears relevant. Basically in the case of 25220 Quail Ridge Road, Escondido, CA, 97027, Google Places is returning a best-guess partial match, and the response should include a partial_match field that we should validate is false (exact matches only).

Okay, I think I’ve figured this out. Basically some addresses don’t have the street_name and route that we’re looking for here.

image

jk it happens with 88 Kearney Street

I’m investigating this now.