Dangling Trips: Trips without a visible trip_end

[avatarneil]

Is your feature request related to a problem? Please describe.

In MDS Agency (and from what I've heard from @quicklywilliam this is an issue for MDS Provider too), it is possible to receive Event & Telemetry information for a trip_id, but never receive an event which includes the trip_end event_type for that trip. I like to call these dangling trips.

Example from an MDS Agency perspective with some partial payloads:

1. Vehicle begins a trip inside a regulating agency's jurisdiction { event_types: ['trip_start'], vehicle_state: 'on_trip', trip_id: '7d7ee01f-db96-4041-808b-a4c5ccd39aa8', ...} received.
2. Rider drives the vehicle around for a while inside of the jurisdiction, Telemetry updates are received.
3. Rider drives outside of the jurisdictional boundaries, { event_types: ['trip_leave_jurisdiction'], vehicle_state: 'elsewhere', trip_id: '7d7ee01f-db96-4041-808b-a4c5ccd39aa8', ... } received.
4. Rider ends trip outside of the jurisdictional boundaries no Event data received.

At this point, it is incredibly hard to know for certain that the trip has actually ended, until you see subsequent activity for the vehicle that is un-associated with the previous trip_id, which is liable to never happen. This makes it impossible to derive almost anything that's reliant on knowing that a trip has actually completed (e.g. metrics, fees, etc...) without making assumptions, such as timing out the trip after x hours of not receiving any events/telemetry for it and calling it complete.

Describe the solution you'd like

A POST to Agency to definitively indicate that a trip has ended if it ever intersected the jurisdictional boundaries. Specifically, a payload which does not include sensitive data (e.g. where the trip ended), as this is liable to be outside of jurisdictional boundaries, and many (dare I say most if not all) agencies do not want to collect this data.

A solution which I personally like a lot is adding a /trips endpoint to Agency, as suggested in a separate (but related) issue #550. There is an inbound PR to accompany #550 which I'll link to once it's been opened against this repo.

Is this a breaking change

A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).

• This could be breaking depending on the solution chosen.

Impacted Spec

For which spec is this feature being requested?

• agency
• (maybe?) provider

Describe alternatives you've considered

Another solution which was proposed on today's WG call by @quicklywilliam would be to modify the state machine somehow to represent this, @quicklywilliam. That being said, I do have some concerns about the feasibility of this, because currently in Agency Telemetry is a required property of Events, and this would violate the desire for there to not be any sensitive outside-of-jurisdiction data.

[avatarneil]

@quicklywilliam If you could add a comment describing how this issue would present under a Provider API workflow, it'd be very appreciated!

[quicklywilliam]

@avatarneil you bet, thanks for filing!

Our experience with "dangling trips" in Provider closely mirrors what it sounds like LA is experiencing with Agency. When a trip leaves the service area, there is inconsistency and indeterminacy around what happens next:

• Pre-1.0, we never hear from it again.
• With 1.0, we get the elsewhere event but we never learn about when the trip actually ends. We can't just assume the trip ended when we get the elsewhere event, because the same trip could re-enter the service area again.

For these reasons, we must resort to using data from the /trips endpoint to accurately assess even basic metrics such as trip counts. I feel that this is not a good system design. For example:

• We can't really build an accurate state of the world without referring to two disparate endpoints.
• Sensitive trip and route data must be shared and transmitted across any system that needs to compute even basic status or count information. This is bad from an op-sec perspective.
• The trips endpoint might not contain every trip we heard about from status. For example, some operators might filter out trips under 100 feet.
• There are limits to how quickly new trips are marshaled into the trips endpoint, so anything approaching "realtime" is difficult.