DataFetchingException (index out of bounds) when planning journey during period of disruption

[miklcct]

Summary

When trying to plan itineraries during period of disruptions (a large number of train delays, cancellations and replacements), OpenTripPlanner produces error in queries.

Expected behavior

Itineraries are returned

Observed behavior

The GraphQL query returns error

{
  "errors": [
    {
      "message": "Exception while fetching data (/plan) : Index 12 out of bounds for length 12",
      "locations": [
        {
          "line": 6,
          "column": 3
        }
      ],
      "path": [
        "plan"
      ],
      "extensions": {
        "classification": "DataFetchingException"
      }
    }
  ],
  "data": {
    "plan": null
  }
}

Repeated queries return the following:

{
  "errors": [
    {
      "message": "Exception while fetching data (/plan) : null",
      "locations": [
        {
          "line": 6,
          "column": 3
        }
      ],
      "path": [
        "plan"
      ],
      "extensions": {
        "classification": "DataFetchingException"
      }
    }
  ],
  "data": {
    "plan": null
  }
}

There is nothing in the OpenTripPlanner console output.

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

e9200c0

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

The Greater London and Surrey maps are used.

The timetable and real-time information can be downloaded here and here (expires 31 days).

Command line used to start OTP

NR_GTFSRT_URL=file:///home/michael/projects/darwin-gtfs-converter/national_rail_gtfsrt.binpb java -Xmx16G -jar otp-shaded.jar --build --save --serve .

Router config and graph build config JSON

The time zone used is Europe/London.

otp-config.json

{
	"otpFeatures" : {
		"GtfsGraphQlApi": true,
		"ParallelRouting": true,
		"TransferConstraints" : true,
		"TransmodelGraphQlApi": true,
		"ActuatorAPI": true,
		"Co2Emissions": true,
		"FaresV2": true,
		"FlexRouting": true,
		"SandboxAPIGeocoder": true,
		"SandboxAPIParkAndRideApi": true
	}
}

build-config.json

{
	"areaVisibility": true,
	"dataImportReport": true,
	"maxTransferDuration": "PT15M",
	"multiThreadElevationCalculations": true,
	"staticBikeParkAndRide" : true,
	"staticParkAndRide" : true,
	"stopConsolidationFile" : "consolidated-stops.csv",
	"subwayAccessTime": "1.0",
	"transitModelTimeZone": "Europe/London",
	"transitServiceEnd": "P3M",
	"transitServiceStart": "P-7D",
	"boardingLocationTags": ["ref", "ref:crs", "naptan:AtcoCode", "naptan:NaptanCode"],
	"gtfsDefaults": {
		"discardMinTransferTimes": true
	},
	"osmDefaults" : {
		"osmTagMapping" : "uk",
		"timeZone" : "Europe/London"
	},
	"transitFeeds" : [
		{
			"type" : "gtfs",
			"feedId" : "DfT",
			"source" : "gtfs-dft.zip"
		},
		{
			"type" : "gtfs",
			"feedId" : "NR",
			"source" : "national_rail_gtfs.zip"
		}
	]
}

router-config.json

{
  "routingDefaults": { 
    "drivingDirection": "left",
    "locale": "en_GB",
    "numItineraries": 10,
    "searchWindow": "PT6H",
    "transferSlack": "PT30S",
    "waitReluctance": 1.76,
    "accessEgress": {
      "maxDuration": "PT2H"
    },
    "walk": {
      "boardCost": 300,
      "reluctance": 1.68
    },
    "wheelchairAccessibility": {
      "trip": {
        "onlyConsiderAccessible": false,
        "unknownCost": 600,
        "inaccessibleCost": 3600
      },
      "stop": {
        "onlyConsiderAccessible": false,
        "unknownCost": 600,
        "inaccessibleCost": 3600
      },
      "elevator": {
        "onlyConsiderAccessible": false
      },
      "inaccessibleStreetReluctance": 25,
      "maxSlope": 0.08333,
      "slopeExceededReluctance": 50,
      "stairsReluctance": 25
    }
  },
  "timetableUpdates": {
    "maxSnapshotFrequency": "PT5S" 
  },
  "transit": {
    "searchThreadPoolSize": 4,
    "transferCacheRequests": [
      {
        "modes" : "WALK",
        "walk" : {
          "boardCost" : 300,
          "reluctance" : 1.68
        }
      },
      {
        "modes" : "WALK",
        "walk" : {
          "boardCost" : 300,
          "reluctance" : 1.68
        },
        "wheelchairAccessibility" : {
          "enabled" : true
        }
      },
      {
        "modes" : "WALK",
        "walk" : {
          "boardCost" : 0,
          "reluctance" : 1.0
        }
      },
      {
        "modes" : "WALK",
        "walk" : {
          "boardCost" : 0,
          "reluctance" : 1.0
        },
        "wheelchairAccessibility" : {
          "enabled" : true
        }
      }
    ]
  },
  "updaters": [
    {
      "type": "stop-time-updater",
      "url": "${NR_GTFSRT_URL}",
      "feedId" : "NR",
      "frequency": "PT27S"
    }
  ]
}

Steps to reproduce the problem

Run the following exact query (it refers to a journey through a period of train disruption)

query GtfsExampleQuery {
  plan(
    from: {lat: 51.520303, lon: -0.104917},
    to:{lat: 51.231734, lon: -0.334611},
    date: "2024-09-17"
    time: "17:30"
  ) {
    itineraries {
      legs {
        from {
          name
        }
        to {
          name
        }
        duration
        route {
          shortName
        }
        headsign
      }
    }
  }
}

The problem doesn't exist if the date is changed to some future dates when real-time data are not yet available.