Legacy OTP code can exacerbate connectivity issues

[barbeau]

Summary:

We have some backwards compatibility code in OBA Android to handle older versions of OpenTripPlanner. This is only used under failure conditions where the main URL isn't responding. Something rare event must have happened yesterday (device, network or server) that tripped this for a few Tampa users at the same time. I received multiple error report emails from users with the 404 errors for the URL being used, which made me think it was a server-side issue. However, while the initial connectivity problem wasn't within the app, the app failing over to the OTP legacy code can exacerbate the problem and cause the user to have connectivity problems planning trips until they restart the app (i.e., the legacy URL keeps getting used and fails with newer OTP versions).

I need to revisit how we're using backwards compatibility for OBA Android and OTP servers, and at this point if Puget Sound is using the newer OTP URL format I should yank out the compatibility code so this doesn't happen again.

Steps to reproduce:

1. Plan a trip and have a series of failed requests

Expected behavior:

1. Recover and successfully plan a trip as soon as network/server connectivity is restored

Observed behavior:

1. If a legacy URL works one, then the app falls back to permanently using that legacy OTP URL. If the legacy URL is removed, the app will never use the new URL unless it's reinstalled.

Device and Android version:

N/A

[barbeau]

Something isn't right with the Sound Transit OTP v1.x API and the new API URL structure - I'm getting an HTTP 404.

Here’s the old Sound Transit OTP API format pre-v1.x that works: http://tpng.api.soundtransit.org/tripplanner/st/plan?date=07-09-2018&mode=TRANSIT,WALK&arriveBy=false&wheelchair=false&optimize=QUICK&showIntermediateStops=true&fromPlace=47.6422,-122.199&toPlace=47.5847,-122.304&time=11:34AM

…and here’s the new Sound Transit OTP API format post-v1.x that gives an HTTP 404: http://tpng.api.soundtransit.org/tripplanner/st/routers/default/plan?date=07-09-2018&mode=TRANSIT,WALK&arriveBy=false&wheelchair=false&optimize=QUICK&showIntermediateStops=true&fromPlace=47.6422,-122.199&toPlace=47.5847,-122.304&time=11:34AM

The same new URL structure works with HART’s OTP server: https://otp.prod.obahart.org/otp/routers/default/plan?date=07-06-2018&mode=TRANSIT,WALK,BICYCLE_RENT&arriveBy=false&wheelchair=false&optimize=QUICK&showIntermediateStops=true&fromPlace=28.0587,-82.4164&toPlace=27.9364,-82.4829&time=05:58PM

[barbeau]

WIP PR at https://github.com/OneBusAway/onebusaway-android/pull/900, pending follow up with Sound Transit

[barbeau]

Sound Transit is using the old URL format with their v1.x OTP deployment, which complicates things. So, we still need to support two different API formats side-by-side for now...

[barbeau]

After looking at this more, the app doesn't save the preference to use the legacy API URL unless there is at least one successful request/response. So something must have happened in the OTP server-side config that exposed a working legacy URL, and then removed it, which resulted in users being stuck using it. Given that we can't easily migrate to the new URL path due to issues with the Sound Transit deployment, and the app should never fall back to the legacy URL unless it works, I'm going to close this for now as a one-time fluke. I'll re-open if it happens again in the future.

[barbeau]

I'm re-opening this - some users that switch to "Bus only" in Tampa could get stuck with the old, bad URL format due to issues with current version of OTP accepting the "Bus only" request parameters - see https://github.com/OneBusAway/onebusaway-android/issues/1014.