trips-for-route returns the same tripId twice (real-time + schedule-only entries)

[bmander]

Summary

The REST API trips-for-route endpoint sometimes returns the same tripId twice in
data.list — once as a real-time entry (with a status.lastKnownLocation GPS fix) and once as a
schedule-only entry (only an interpolated status.position, no fix), each with a different
status.distanceAlongTrip. Consumers that key a vehicle/marker by trip id then get two conflicting
records for one trip.

Observed via the OneBusAway Android client against the Puget Sound region (agency 1 /
King County Metro), trips-for-route with includeStatus=true, API v2.

Evidence

Captured from live responses (client-side logging of the parsed list). Every duplicate was a trip id
paired against itself — one entry with a GPS fix, one without:

tripId=1_811078050  distanceAlongTrip=19955.9  lastKnownLocation=null                 position=47.60219,-122.33088
tripId=1_811078050  distanceAlongTrip=20074.0  lastKnownLocation=47.60121,-122.33026  position=47.60130,-122.33027

tripId=1_800781650  distanceAlongTrip=0.05     lastKnownLocation=null                 position=47.57755,-122.29721
tripId=1_800781650  distanceAlongTrip=94.08    lastKnownLocation=47.57801,-122.29789  position=47.57803,-122.29791

tripId=1_736400070  distanceAlongTrip=7153.3   lastKnownLocation=47.62271,-122.29730  position=47.62144,-122.29919
tripId=1_736400070  distanceAlongTrip=7109.9   lastKnownLocation=null                 position=47.62116,-122.29958

The two entries for a trip disagree on distanceAlongTrip (and therefore position) by anywhere from a
few meters to ~500 m. The condition is common and transient — it appears most often when a vehicle is
near a trip terminal / rolling between trips in its block.

Questions

1. Is a trip appearing more than once in a single trips-for-route response intended? If so, what
   distinguishes the entries — is one the scheduled/predicted view of the trip and the other the
   real-time vehicle, and is there a documented field a client should use to pick the canonical one?
2. If it is not intended, the endpoint should emit one entry per active trip (preferring the
   real-time/AVL-backed status).

Client impact (for context)

On the OneBusAway Android real-time vehicle map, the two entries render as two vehicles sharing one
trip-id marker key; the marker's position then flips between the GPS fix and the scheduled point every
frame (a visible per-frame flicker). It also feeds two conflicting observations per trip into the
client's extrapolation state. We've worked around it client-side by de-duplicating the list by trip id
(keeping the GPS-fix entry), but the duplicate ideally shouldn't be emitted — or its semantics should
be documented so clients can rely on them.

Happy to provide full raw JSON captures if useful.