Cancelation of invalid SIRI extra journey leads to travel back in time

[vpaturet]

Some combinations of SIRI updates let the transit data in an inconsistent state where trips travel back in time. The error is caught by Raptor and the corresponding trips are ignored: Traveling back in time is not allowed. Board time: 00:11:25+3d, alight stop pos: 0, stop arrival time: 01:59:25+3d, trip: TripScheduleWithOffset{info: BUS R13B #30962, pattern.id: RB:XXX:Line:L13B::622:RT, depart: 21:21:40}.

One sequence of messages causing this error is the following:

1. Create an extra journey with invalid planned data (travel back in time) and valid real time data:

   <EstimatedVehicleJourney>
   <EstimatedVehicleJourneyCode>XXX:ServiceJourney:7c55cc0a-a50f-4fde-9a86-e99bbccea91b-1622-2023-11-21-9</EstimatedVehicleJourneyCode>
   <ExtraJourney>true</ExtraJourney>
   <EstimatedCalls>
       <EstimatedCall>
           <AimedDepartureTime>2023-11-21T10:58:48.174+01:00</AimedDepartureTime>
           <ExpectedDepartureTime>2023-11-21T10:48:06.129+01:00</ExpectedDepartureTime>
       </EstimatedCall>
       <EstimatedCall>
           <AimedArrivalTime>2023-11-21T10:08:48.174+01:00</AimedArrivalTime>
           <ExpectedArrivalTime>2023-11-21T10:58:06.129+01:00</ExpectedArrivalTime>
       </EstimatedCall>
   </EstimatedCalls>
   </EstimatedVehicleJourney>

2. Cancel the extra journey:

NSB:ServiceJourney:7c55cc0a-a50f-4fde-9a86-e99bbccea91b-1622-2023-11-21-9 true true ``` ## Version of OTP used (exact commit hash or JAR name) dev-2.x ## Data sets in use (links to GTFS and OSM PBF files) Norwegian transit data

[leonardehrenfried]

Is this the long running problem that Entur has been trying to figure out for months?

[vpaturet]

Absolutely. It is no longer critical since invalid trips are filtered out in Raptor, but it would be nice to have a complete fix. The module test helps a lot.