Bank Account - Some addresses give error without red outline and no information on what's wrong

[isagoico]

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. Navigate to workspace
2. Click on add bank account
3. Connect with test credentials
4. On the company address enter "64 Noll Street, Brooklyn, NY, USA" and select the option
5. Enter the rest of the information in the fields
6. Press continue.

Expected Result:

There's a error message mentioning the user what is wrong with the provided address.

Actual Result:

There's no information on why the address is not valid. Some addresses are valid and I have no idea why some are not.

Workaround:

Enter a valid address (?) I guess this is not valid if the user is entering a correct address here.

Platform:

Where is this issue occurring?

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

Version Number: 1.1.7-22

Reproducible in staging?: Yes
Reproducible in production?: No

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:

Issue reported by: Applause
Slack conversation:

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @tylerkaraszewski (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[isagoico]

Oh I think this is related to this PR #5854 - @aldo-expensify

[aldo-expensify]

The problem with that address and the result clicked is that the result is missing the locality that we use as the "city".

JSON obtained from the result:

[
    {
        "long_name": "64",
        "short_name": "64",
        "types": [
            "street_number"
        ]
    },
    {
        "long_name": "Noll Street",
        "short_name": "Noll St",
        "types": [
            "route"
        ]
    },
    {
        "long_name": "Bushwick",
        "short_name": "Bushwick",
        "types": [
            "neighborhood",
            "political"
        ]
    },
    {
        "long_name": "Brooklyn",
        "short_name": "Brooklyn",
        "types": [
            "sublocality_level_1",
            "sublocality",
            "political"
        ]
    },
    {
        "long_name": "Kings County",
        "short_name": "Kings County",
        "types": [
            "administrative_area_level_2",
            "political"
        ]
    },
    {
        "long_name": "New York",
        "short_name": "NY",
        "types": [
            "administrative_area_level_1",
            "political"
        ]
    },
    {
        "long_name": "United States",
        "short_name": "US",
        "types": [
            "country",
            "political"
        ]
    },
    {
        "long_name": "11206",
        "short_name": "11206",
        "types": [
            "postal_code"
        ]
    },
    {
        "long_name": "4604",
        "short_name": "4604",
        "types": [
            "postal_code_suffix"
        ]
    }
]

[aldo-expensify]

Well, it seems like there will be cases where the "locality" (which is often a city) is missing:

https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete-addressform

https://stackoverflow.com/questions/44774508/why-city-name-missing-for-some-locations-from-google-maps-api-result

Would be interesting to know which other cities in the US may have this problem.

What can we do about it? in this case we could use the administrative_area_level_1 if the locality is missing, but I'm not sure if that will work in all cases. I think the administrative_area_level_1 is the state, and in this case it matches the city name.

[kevinksullivan]

Removing deploy blocker per https://expensify.slack.com/archives/C020EPP9B9A/p1634274922234500

[aldo-expensify]

In the details of the selected result we have the location's coordinate. In the case of the address 64 Noll Street, Brooklyn, NY, USA , the latitude is 40.7007309 and longitude is -73.9332924.

I did a test to reverse geocode coordinates to see if that would find me the city. Api url request based on the coordinates:

https://maps.googleapis.com/maps/api/geocode/json?latlng=40.7007309,-73.9332924&key=XXX

(you can open this URL in the browser, if you have an api key - I found a key in slack)

This gives a bunch of results, but within the results, there was one that indeed had the city:

response.results.find(result => result.address_components.find(component => component.types.includes('locality')))

This yields

'{
    "address_components": [
        ...
        {
            "long_name": "New York",
            "short_name": "New York",
            "types": [
                "locality",
                "political"
            ]
        },
       ...
    ],
    ...
}'

I don't know yet how reliable is this. If it was reliable, would we consider following such approach? I did a few tests using addresses from Brooklyn, Bronx and Queens, which have the missing city problem, and I always found the city using the reverse geocoding.

The function I'm playing with looks like:

const reverseGeocode = (latitude, longitude) => {
        const apiKey = 'XXX';
        const proxiedUrl = `/geocode/json?latlng=${latitude},${longitude}&key=${apiKey}`;
        const url = `${CONFIG.EXPENSIFY.URL_EXPENSIFY_COM}api?command=Proxy_GooglePlaces&proxyUrl=${proxiedUrl}`;

        //`https://maps.googleapis.com/maps/api/geocode/json?latlng=${latitude},${longitude}&key=${apiKey}`
        fetch(url)
            .then(response => response.json())
            .then((response) => {
                console.log(response);
                const resultWithCity = response.results.find(result => result.address_components.find(component => component.types.includes('locality')));
                console.log(resultWithCity);
            });
    };

[aldo-expensify]

@marcaaron @roryabraham what do you think about this? Would appreciate your opinion.

[marcaaron]

Can you summarize the problem? I'm not sure I understand what the issue is.

[aldo-expensify]

Can you summarize the problem? I'm not sure I understand what the issue is.

1. Input an address in Brooklyn, i.e. "64 Noll Street, Brooklyn, NY, USA",
2. Select the only result offered
3. We get the different parts of the address (city, state, zipCode, streetName, streetNumber) from address_components in the result. In particular, we get the city from the "locality" address_components (see all address_components available here).
4. There are some results that have the "locality" missing (some parts of NY, don't know if other places)
5. This ends up blocking the user. The only result available is incomplete.

Currently this is affecting address in Brooklyn, Bronx and Queens, not sure if there are other neighbourhoods/cities with the problem.

One option I'm thinking about, is to complement the information using the the geocode API when there is something missing:

• We get coordinates from the results from the places API
• We can use those coordinates for the geocode API to get the missing city

Another option would be to just hardcode the problematic case of New York city, but we don't know if there could be other problematic cities.

[marcaaron]

complement the information using the the geocode API when there is something missing

This sounds like something we may have to do anyway once we exhaust other alternatives. Tbh, I'm not sure what else could be done and the form is currently in a bad state. This is an edge case, but an important one (lots of people live in cities - if we can assume other cities like New York are affected). So, maybe we should be fixing this any way we possibly can and then discuss the good approach after 😄

Can we rule out that simply preferring to use the sublocality field if it's available and locality is unavailable? In this case, "Brooklyn" is the city we are looking for. It looks like the JSON you linked has that in it.

There are some results that have the "locality" missing (some parts of NY, don't know if other places)

I think we only need to worry about the US at the moment. Unsure if that helps narrow it down. I took a look at the docs you linked and I'm no less confused. I wish I could help more but don't have much experience with this API.

[roryabraham]

I would be hesitant to start using the GPS coordinates to validate addresses – seems like that could lead to a near-infinite number of false positives if we're not careful, so if we can't find another solution I would prefer to hardcode the known exceptions of the boroughs of NYC.

But before going down that road, let's try what @marcaaron suggested and fall back on the sublocality if locality is missing? In any event, I really think the key to success on this component is unit tests. That way we can still manage to keep it working despite any hackiness or workarounds we have to implement.

[aldo-expensify]

I would be hesitant to start using the GPS coordinates to validate addresses – seems like that could lead to a near-infinite number of false positives if we're not careful

I was thinking that how prone to error it is depends on the type of information that we are trying to complete. A city probably would be correct by GPS coordinates, but a street could be more likely to be wrong.

In any case, since NY seems to be the only problematic case at the moment, I agree with you both of using sublocality if locality is missing for now and see if later other cases arise. Using this simpler solution may be enough.

What do we use the address information for? there won't be any problem in using Brooklyn as the city?

[marcaaron]

there won't be any problem in using Brooklyn as the city?

Nope, Brooklyn is the city.

[aldo-expensify]

Nope, Brooklyn is the city.

😮 🤯

[tylerkaraszewski]

I was assigned for triage but it looks like @aldo-expensify has this so I'm unassigning myself.

[ogumen]

From the accessibility prospective, it fails WCAG success criteria 3.3.1 and 3.3.3 since it is not clear what the error is and how to fix it.

[aldo-expensify]

Not overdue, PR waiting for review.

From the accessibility prospective, it fails WCAG success criteria 3.3.1 and 3.3.3 since it is not clear what the error is and how to fix it.

We will continue having poor error feedback for this field once the PR is merge, we should address this later. Two cases that will cause an error with poor feedback:

• User types an address without selecting a result from the autocomplete
• User selects a result from the autocomplete, but that result is not valid for us (route).