Distance - Countries, which begin with entered letter are displayed next to suggested places

[kbecciv]

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.21-4
Reproducible in staging?: y
Reproducible in production?: n
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
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Issue found when executing PR #33887

Action Performed:

1. Go to URL https://staging.new.expensify.com/
2. Login with any account
3. Create a workspace and go to your workspace expense chat
4. Create a distance request and allow the browser to give your location
5. Type an a in the first waypoint and confirm that the locations offered are biased by your real location

Expected Result:

The locations offered are biased by your real location

Actual Result:

When the location is turned on, along with the locations offered depending on your real location, countries whose names begin with the entered letter are displayed next

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

Bug6332062_1704367872635.bandicam_2024-01-04_10-01-33-992.mp4

View all open jobs on GitHub

[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.

[melvin-bot]

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

[paultsimura]

Proposal

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

What is the root cause of that problem?

The location bias of Google Places search is not strictly limiting the results to fit into the predefined location bias: https://stackoverflow.com/a/59850360

It seems like the countries have a high rank in Google places search results, therefore they are returned in the search results even though they are not within the provided boundaries.

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

I would suggest not showing countries in the search results at all, since the distance requests are expensable by mileage, and "trip from Poland to the USA" is a very unclear distance.

For this, we can filter out the search results with type: country here:

App/src/components/AddressSearch/index.js

Lines 442 to 451 in a2fc252

	renderRow={(data) => {
	const title = data.isPredefinedPlace ? data.name : data.structured_formatting.main_text;
	const subtitle = data.isPredefinedPlace ? data.description : data.structured_formatting.secondary_text;
	return (
	<View>
	{title && <Text style={[styles.googleSearchText]}>{title}</Text>}
	<Text style={[styles.textLabelSupporting]}>{subtitle}</Text>
	</View>
	);
	}}

What alternative solutions did you explore? (Optional)

We can also leverage the Google Places' query.types parameter, which allows limiting search results to specific types of points, but it will require us to decide which specific types we want to use for Distance requests. Here are the example values: https://developers.google.com/maps/documentation/places/web-service/supported_types

[youssef-lr]

cc @aldo-expensify could this be related to your PR? Regardless, what do you think about the proposal above removing countries from the suggestions all together?

[allroundexperts]

cc @rojiphil Since you authored this feature and might have a better idea on how to fix!

[youssef-lr]

Yeah I'm not sure about hiding countries to be honest, it sounds like we would be fixing a symptom instead of the actual problem. Because this isn't happening in production according to @kbecciv.

[allroundexperts]

The feature as a whole is not yet on staging. This was the original PR.

[paultsimura]

Because this isn't happening in production

It is actually, but in Prod the results are currently not location-biased at all, so it isn't noticeable that much (e.g. India, Israel, UK here):

[aldo-expensify]

Good point @paultsimura , I think we should remove this as a deploy blocker then, and treat it as a separate issue

[marcaaron]

Can a distance request be created from one country to another? Sounds weird, but if it works then maybe someone wants to do it.

I feel like the countries (if left in) should be prioritized last in the list after any more specific possible locations.

Also agree this doesn't need to be a blocker.

[melvin-bot]

Triggered auto assignment to @trjExpensify (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.

[paultsimura]

Just to give a little more info about why the countries appear in the list even though they are outside of the boundaries: https://developers.google.com/maps/documentation/javascript/reference/places-service#LocationBias

A LocationBias represents a soft boundary or hint to use when searching for Places. Results may come from outside the specified area...

[aldo-expensify]

Can a distance request be created from one country to another? Sounds weird, but if it works then maybe someone wants to do it.

It does make sense to me, you could drive across small countries in Europe for example :). What I think doesn't make sense is that the suggestion shows a Country (not an address in a country). It doesn't make sense to me to calculate distances between "countries" without specific addresses.

[trjExpensify]

yeah, agree with Aldo there. @thienlnam what was the intention from the OG issue here?

[thienlnam]

Here's the OG issue for this feature. If we chose a starting location, we wanted the destination or stop autocomplete to be around where the starting location was as opposed to showing places that were in different states entirely.

Agree with others that this isn't a blocker - but I do think we should remove countries from the results. I can't really think of a situation where you would do that - especially since we're calculating mileage from one address to another

[trjExpensify]

Yeah, I think you should be allowed to put in addresses across countries, but claiming mileage for "UK" to "France" is not a legit case, so we should remove countries in the results.

[trjExpensify]

@rojiphil @parasharrajat @thienlnam will you guys take this over as a clean-up from this?

[rojiphil]

will you guys take this over as a clean-up #33334?

@parasharrajat @thienlnam

I am not sure of the cleanup that needs to be done as part of the PR here

As I understand, we are using Google Place Autocomplete service (ref)to arrive at our place predictions. Based on the input provided, the Autocomplete service would return 5 place predictions after ordering results based on perceived relevance. Before adding locationbias, we would get results from faraway places even though there were relevant results near the waypoints. Now, after adding locationbias, we get results from nearby locations if relevant predictions are available nearby. This is what we have done in the PR.

However, I think the issue here is independent of the recently implemented locationbias feature as we have not altered the logic of the type of results returned. The existing code uses address type as mentioned here and here which seems to be root cause of this issue. The address type does not seem to prevent results of type country. Also, there could be other unwanted types like continent that can come in.
Maybe, the owners of react-native-google-places-autocomplete library have an answer for this.

What are your thoughts?

[paultsimura]

I agree that it's not related to the location bias feature and wasn't introduced by it.

The existing code uses address

We explicitly pass no resultTypes to not limit the search results here, and using pre-defined resultTypes is mentioned in my proposal as an alternative solution (however it's quite limited): #33941 (comment):

App/src/pages/iou/request/step/IOURequestStepWaypoint.js

Line 256 in 7ae1ec7

resultTypes=""

[rojiphil]

That's the solution then. Passing address will solve the problem then. I thought address is still not solving the problem. And the root cause is that address is not used.

[paultsimura]

Passing address will solve the problem then.

Unfortunately no: it will return only locations with precise addresses: no businesses, no landmarks. And that's most likely undesirable.

Without type:address

With type:address

The issue is that Google doesn't allow combining these types for a more refined search:

Only a single type from Table 3 is allowed in the request. If you do specify a value from Table 3, you cannot specify a value from Table 1 or Table 2.

That's why I suggest manually filtering out unwanted types post-search.

[rojiphil]

That's why I suggest manually filtering out unwanted types post-search.

Manually filtering seems to be a workaround as we will have to identify all undesirable types. Also, the side-effect is that we will see less than 5 results sometimes. And worse, none if all turn out to be of the same kind.

[rojiphil]

Unfortunately no: it will return only locations with precise addresses: no businesses, no landmarks. And that's most likely undesirable.

That's a good point. Maybe, that's why types is left empty.
We have finer controls with the new Places API. But, unfortunately, the library we use depends on Google Place Autocomplete service.
The other alternative is for the library to support the new Places API to take advantage of the recent advancements.

[trjExpensify]

Okay, so if I'm understanding this correctly:

Filtering out countries in isolation is a limitation of the version of the Google Places API we use (coming from upstream library), and doing so would cause us to miss out on including things like businesses and landmarks that we don't want. Is that correct?

[rojiphil]

Filtering out countries in isolation is a limitation of the version of the Google Places API we use (coming from upstream library), and doing so would cause us to miss out on including things like businesses and landmarks that we don't want. Is that correct?

That's correct

[trjExpensify]

Cool, so I would lean on the side of closing this out and revisiting it when the library upstream supports the new Places API. CC: @youssef-lr @marcaaron @aldo-expensify @thienlnam for thoughts!

[aldo-expensify]

That plan sounds good to me, I don't think this is high priority and we can wait.

[thienlnam]

I agree we might have some false-positives trying to post process the countries out of the results manually. I don't mind putting this on hold but it may be disruptive for the users that actually try to use this feature (Not sure how often the countries show up when searching for a place but in the video it seems like it is almost every search)

[trjExpensify]

I don't mind putting this on hold but it may be disruptive for the users that actually try to use this feature

I'm sure we'll get that feedback if its the case.

Sidebar: I think location bias might have had some unwanted side effects, but we can move here (internal ref) on that one as a next step!