Clarification of associated_trips in Provider API Status Changes endpoint?

[oderby]

I'm curious to hear more about the associated_trips field in a status change. My questions are:

• Why/when would a single reservation event have multiple trips related to it?
• What additional information does this field provide that you couldn't determine by joining with trips on device_id and event_time?

[noonhub]

Additionally, this field is marked with "Optional based on device". What types of devices would this be not required for?

[hunterowens]

@oderby perhaps a associated_trip would have been more accurate.

since timestamps can be ever so slightly different depending on hundreds of reasons, associated_trips gives us a join key that can be considered authoritative based on the providers internal user data without requiring us to ask for personally identifiable information.

@noonhub should read "optional based on event_type_reason. will clarify. (ie, a re-balancing action doesn't have an associated trip.

[oderby]

@hunterowens is there a reason why we wouldn't fix it? That is, could we change it to just be named associated_trip of type UUID, which can be omitted? It'd be a breaking change, but that's why the spec is versioned, right? As it stands right now, it's misleading and seemingly wrong (we never expect to handle multiple trips associated with an event).

[thekaveman]

I'm reopening this issue because I'm not convinced it was adequately solved, as @oderby points out.

Is there a case where multiple values should show up in this array? I don't quite understand that yet. If not, can we add to 0.2.1 and make this an optional UUID as suggested by @oderby. It's no more breaking in my mind than #146, which has already been slated for inclusion...

[thekaveman]

PING @hunterowens, any additional thoughts on this?

FWIW, in practice I haven't seen this field being populated at all...

[black-tea]

I have seen a provider add data into this field (when it applies). However, I have never seen two trip IDs for that field and I am not sure the circumstances we would see more than one.

[hunterowens]

I think we can put togehter a PR to only associate each status change with 1 trip and merge in. This is a breaking change, however, since [] of trip_id != trip_id.

[black-tea]

@hunterowens One additional clarification question: Right now, under the Required/Optional, the field is listed as "Optional based event_type_reason". Would a provider be in compliance if it never provided the associated_trips field?

My understanding is that the field is required for user-generated event types? If so, would it be more clear to be listed as 'Required if applicable based on event_type_reason', with the requirement being any user-generated event_type? Or perhaps I am mistaken?

[hunterowens]

Closed with #217