Stale services are used for journey planning

[miklcct]

Expected behavior

The services are no longer returned when an added service disappears from the feed.

Observed behavior

The services are used to return journey results even after it has been removed from the FULL_DATASET feed.

Version of OTP used (exact commit hash or JAR name)

2.7.0-SNAPSHOT

Data sets in use (links to GTFS and OSM PBF files)

GTFS: combined_gtfs.zip
OSM: Greenwich.osm.zip (extract the PBF from the zip)
RT feeds:
test_gtfsrt.zip (extract to get the 2 binaries), text shown below.

RT feed version 1

header {
  gtfs_realtime_version: "2.0"
  incrementality: FULL_DATASET
  timestamp: 1729862503
}
entity {
  id: "ADD_1"
  trip_update {
    trip {
      trip_id: "ADD_1"
      start_time: "10:00:00"
      start_date: "20241101"
      schedule_relationship: ADDED
      route_id: "Cable Car"
    }
    stop_time_update {
      stop_sequence: 0
      arrival {
        time: 1730455200
      }
      departure {
        time: 1730455200
      }
      stop_id: "9400ZZALGWP1"
    }
    stop_time_update {
      stop_sequence: 1
      arrival {
        time: 1730455500
      }
      departure {
        time: 1730455500
      }
      stop_id: "9400ZZALRDK1"
    }
  }
}

RT feed version 2:

header {
  gtfs_realtime_version: "2.0"
  incrementality: FULL_DATASET
  timestamp: 1729862504
}
entity {
  id: "ADD_2"
  trip_update {
    trip {
      trip_id: "ADD_2"
      start_time: "14:00:00"
      start_date: "20241102"
      schedule_relationship: ADDED
      route_id: "Cable Car"
    }
    stop_time_update {
      stop_sequence: 0
      arrival {
        time: 1730556000
      }
      departure {
        time: 1730556000
      }
      stop_id: "9400ZZALGWP1"
    }
    stop_time_update {
      stop_sequence: 1
      arrival {
        time: 1730556300
      }
      departure {
        time: 1730556300
      }
      stop_id: "9400ZZALRDK1"
    }
  }
}

Note that the bug doesn't exist if ADD_2 runs on the same day as ADD_1.

Command line used to start OTP

java -Xmx16G -jar otp-shaded.jar --load --save --serve workspace

Router config and graph build config JSON

build-config.json

{
	"transitModelTimeZone": "Europe/London",
	"transitServiceEnd": "P3M",
	"transitServiceStart": "P-7D",
	"boardingLocationTags": ["naptan:AtcoCode", "naptan:NaptanCode"],
	"osmDefaults" : {
		"osmTagMapping" : "uk",
		"timeZone" : "Europe/London"
	},
	"transitFeeds" : [
		{
			"type" : "gtfs",
			"feedId" : "GB",
			"source" : "combined_gtfs.zip"
		}
	]
}

otp-config.json

{
  "updaters": [
    {
      "type": "stop-time-updater",
      "url": "file:///Users/Michael/transport%20data/test_gtfsrt.binpb",
      "feedId" : "GB",
      "frequency": "PT1S"
    }
  ]
}

Steps to reproduce the problem

1. Start OTP with the above config, feed the v1 RT feed into the updater, and query for a journey from Royal Docks to Greenwich at 2024-11-01 09:50. You are told to take the cable car at 10:00.

2. While the OTP is still running, feed the v2 RT feed into the updater, and query for the same journey again. You are still told to take the cable car at 10:00, but it no longer exists in the feed.

3. Query for a journey between the same origin and the destination, but at 2024-11-02 13:50. You are told to take the cable car at 14:00 as expected.

[miklcct]

The problem also appears if the new GTFS-RT update doesn't contain any updates for a particular trip pattern, and in this case the live times will become stale for the journey planner.

Observed behaviour:

If there is a pattern X with multiple trips A B C with live times on A, sending a feed update contains live times for C only will return A to scheduled times; however, if the feed update contains no live times for A, B or C, the live times for A will be kept and become stale.

[miklcct]

I have now just discovered a related issue:

The following screenshot is the journey planner result.

The following is after the live times are loaded, as seen, the connection is fouled.

However, the journey planner was called well after the live times became actual, which indicates that the journey planner didn't pick up the delayed arrival of the first train. However, it did pick up both delayed departure and arrival of the second train. The first train departed on time but was delayed on the journey.

The server I am using should already have the PR patched, so I'll need to investigate again if it is still this bug, or it is related to direct pattern transfers.