## Delivery Zone Issue Investigation Notes

**Disclaimer** Theres a lot going on here with a lot of moving parts and its going to take some time to fully untangle everything. A large part of the issue with Ilir's particular example comes down to the address itself and the location of the shop, Amici's East Coast Pizzeria (shop id 14248).. The address `3000 Sand Hill Rd 4 210, Menlo Park, CA, 94025` which includes the trailing `4 210` after the road seems to elicit odd behavior from Google's different geocoding endpoints.

**TLDR** It seems that theres odd behavior coming from both Google via Location Service as well as odd behavior coming from the apps. In this particular case, the example is exacerbated by this specific address and the location of the shop in relation to it.

#### Initial Setting Of A Delivery Address
In the apps (iOS specifically), it seems like they reach out to the Location Service's `/autocomplete` endpoint which will return a Google `place_id` which is then used against the Location Service's `/location-from-place-id` endpoint to return the full address details.

The Location Service also has a `/location-from-address` which is sometimes used (web definitely makes use of this) to also return full address details.

Using the address from llir's example `3000 Sand Hill Rd 4 210, Menlo Park, CA, 94025` when setting up your initial delivery address on the `Add New Address` screen on iOS results in an Autocomplete response looks like this:

[
  {
    "id": "EjIzMDAwIFNhbmQgSGlsbCBSZCA0IDIxMCwgTWVubG8gUGFyaywgQ0EgOTQwMjUsIFVTQSI8GjoKMRIvChQKEgmZxnAoVqSPgBHUYELZEc5KCBC4FyoUChIJKQEMSOWkj4ARYZcOd3my818SBTQgMjEw",
    "suggested_address": "3000 Sand Hill Rd 4 210, Menlo Park, CA 94025, USA",
    "main_text": "3000 Sand Hill Rd 4 210",
    "secondary_text": "Menlo Park, CA 94025, USA"
  }
]

The `id` is then passed through to location by place id endpoint which returns:

{
  "borough": null,
  "building_number": "3000",
  "city": "Menlo Park",
  "country": "United States",
  "county": "San Mateo County",
  "county_code": "San Mateo County",
  "full_address_string": "3000 Sand Hill Rd 4 210, Menlo Park, CA 94025",
  "latitude": 37.4188769,
  "location_type": "RANGE_INTERPOLATED",
  "longitude": -122.2205292,
  "neighborhood": null,
  "state": "CA",
  "state_long": "California",
  "street": "Sand Hill Rd",
  "township": null,
  "unit": "4 210",
  "zip_code": "94025",
  "zip_code_suffix": null
}

This places the lat/longs here on the map which happens to be just outside of the shop's delivery zone.
The result of this is that when this lat/lon is used in a subsequent search request, the shop doesn't show up on any results that filter by `delivers_to`.

Looking at the results return on iOS, it does appear that Amici's East Coast Pizzeria only shows up under the `Closest Pie Nearby` and `Pickup Picks Near You` feed modules as both of those feed modules are included in the overall delivery feed but neither of them actually only restrict results to shops that just deliver. This could be changed so that these feed modules do infact filter out shops that dont deliver as one would expect on the delivery feed. It seems logical that one overlooks the names of the feed modules and assumes anything thats returned on the full delivery feed should deliver.

**With that being said, the autocomplete -> place id request secquence of events does seem to incorrectly place the delivery address's lat longs outside of the delivery zone.** I believe this is mainly a result of the trailing `4 210` in the address. Without the trailing `4 210` address part, the location seems to be correctly geocoded to a location that would be inside the shop's delivery zon:

Switching to the using the Location Service's `/location-from-address` endpoint wouldnt fix the issue with this particular address. Hitting the Location Service's `/location-from-address` endpoint with the same address, `3000 Sand Hill Rd 4 210, Menlo Park, CA 94025, USA`, returns the following response:

{
  "borough": null,
  "building_number": "210",
  "city": "Menlo Park",
  "country": "United States",
  "county": "San Mateo County",
  "county_code": "San Mateo County",
  "full_address_string": "210 Sand Hill Cir 4, Menlo Park, CA 94025",
  "latitude": 37.4250499,
  "location_type": "ROOFTOP",
  "longitude": -122.2209919,
  "neighborhood": "Sharon Heights",
  "state": "CA",
  "state_long": "California",
  "street": "Sand Hill Cir",
  "township": null,
  "unit": "4",
  "zip_code": "94025",
  "zip_code_suffix": "7105"
}

This places the lat/longs on the map here:
While this looks more correct and is inside the shops delivery zone, note that the `full_address_string` has been overwritten by Google to `210 Sand Hill Cir 4, Menlo Park, CA 94025` which seems like Google is keying in on the `4 210` part and trying to guess how to make sense of it.

I think the overall takeaway here is that addresses with these funky non-standard numeric parts, either in the prefix or suffix of the address results in unreliable results coming back from Google.

#### Validating Deliverability Of An Order
In Ilir's example, his order was setup for delivery, however, clicking on Amici's East Coast Pizzeria from one of the `Closest Pie Nearby` and `Pickup Picks Near You` feed modules ( these modules dont always return shops that deliver) allows him to start filling up a cart as if the order was for delivery. When you go to check out and review the order, thats where the deliverability check takes place and alerts you to the fact that the shop doesn't deliver:

I tried recreating the example on my phone and when looking into the DataDog RUM traces, I noticed some odd behavior coming from the app - The app appears to initially make a call to Core's `/api/v1/shops/14248/delivery_address` endpoint to check deliverabiltiy on the `Review Order` screen. It appears as though the app is actually stripping the `4 210` part of the address out when making the call to Core. This lead me to believe that in this particular edgecase, the order should have gone through just fine since deliverability was being determined based on the address `3000 Sand Hill Rd, Menlo Park, CA 94025, USA` which should have geocoded correctly.

However, when looking at the [DataDog traces ](https://app.datadoghq.com/rum/explorer?query=%40usr.email%3Ascott.berke%40slicelife.com%20%40type%3Aview&cols=&event=AQAAAYPYEZemvWvKWgAAAABBWVBZRVplbUFBQWFKVU9WMkpmNjBQbF8&p_tab=resources&spanID=451454042436741164&viz=stream&from_ts=1665780903765&to_ts=1665782703765&live=true)for my session, I noticed that multiple calls were being made to the `delivery_address` endpoint. In the below screenshot I see multiple requests being made to this endpoint in rapid succession:
Interestingly, the `200` responses at the bottom of the trace list all seem to use the address `3000 Sand Hill Rd, Menlo Park, CA 94025, USA` as well as the correct `shop_id` and indicate based on the response that the shop **does** deliver to the provided address. The other calls being made that result in a `404` (indicating that the shop doesnt deliver) either use the `3000 Sand Hill Rd, Menlo Park, CA 94025, USA` with an incorrect `shop_id` (in this case, they were using a `shop_id` from a previous shop I was testing with and adding items to my cart) or they were making the call with `3000 Sand Hill Rd, Menlo Park, 94025` where the state (CA) was being left out of the request. When the state was left out, the geocoding seems to also get wonky and subsquently returns that the shop doesnt deliver to the provided address.

I don't understand whats causing the mulitple requests in succession to `/api/v1/shops/14248/delivery_address` with different params and will need to sync with the apps teams to understand more. Given that there were `200` resposnes being returned, I'm not sure why those werent being used to indicate that delivery was available. In this extreme edgecase it seems there were elements causing the shop to not return in the list of shops that deliver when it should have been included and also elements that prevented the shop from validating its ability to deliver on the review order screen.

I see calls being made during my user session with multiple unique requests:
- `https://consumer.prod.slicelife.com/services/core/api/v1/shops/52366/delivery_address?location=3000%20Sand%20Hill%20Rd%2C%20Menlo%20Park%2C%20CA%2094025`
- `https://consumer.prod.slicelife.com/services/core/api/v1/shops/14248/delivery_address?location=3000%20Sand%20Hill%20Rd%2C%20Menlo%20Park%2C%2094025`
- `https://consumer.prod.slicelife.com/services/core/api/v1/shops/52366/delivery_address?location=3000%20Sand%20Hill%20Rd%2C%20Menlo%20Park%2C%20CA%2094025`
- `https://consumer.prod.slicelife.com/services/core/api/v1/shops/14248/delivery_address?location=3000%20Sand%20Hill%20Rd%2C%20Menlo%20Park%2C%20CA%2094025`