Method isTripActive able to check the delay cases in StopTimeUpdate

[TsimurSh]

Hi, Please take a look at this change. Unfortunately, this method will regret all trips and mark them as inactive if the tripUpdates use a delay in the stopTimeUpdate.

[CLAassistant]

All committers have signed the CLA.

[aaronbrethorst]

Thanks for your contribution. Can you elaborate on the scenario you’re solving for and also add tests that validate it?

[TsimurSh]

Ok. I added a test. Problems what it solve: In normal GTFS-realtime updates, trip predictions are considered active if:

• There’s at least one stop time update,
• And its first and last stop predictions fall within a valid time window. But sometimes a TripUpdate:
• Lacks timestamps (i.e., no arrival.time),
• Only has a delay

The previous logic would fail in such a case because it relies on arrival/departure time values.

@aaronbrethorst Take a look at.