Searches using long-running trips non-deterministic

[gmellemstrand]

NOTE: this issue system is intended for reporting bugs and tracking progress in software development. For all other usage and software development questions or discussion, please write to one of the mailing lists (Google groups):
https://groups.google.com/forum/#!forum/opentripplanner-dev
https://groups.google.com/forum/#!forum/opentripplanner-users

In preparation for #3162 I've been testing the dev-2.x branch with ADDITIONAL_SEARCH_DAYS_BEFORE_TODAY set to 10 in order to support the long-running Hurtigruten trips. This will of course add the additional days for all trips, not just the Hurtigruten trips. Performance will be worse, but the functionality should be the same.

The test-search I've been using, boards the trip several days after its first departure.

{
  trip(from: {place: "RB:NSR:Quay:99534"}, to: {place: "RB:NSR:Quay:99514"}, dateTime: "2020-09-26T07:10:32.764+02:00") {
    messageEnums
    metadata {
      nextDateTime
      searchWindowUsed
    }
    tripPatterns {
      startTime
      duration
      walkDistance
      legs {
        mode
        line { id }
        aimedStartTime
        aimedEndTime
      }
    }
  }
}

Expected behavior

A trip result using the long-running Hurtigruten boat is returned.

{
  "data": {
    "trip": {
      "messageEnums": [],
      "metadata": {
        "nextDateTime": "2020-09-26T10:10:32+02:00",
        "searchWindowUsed": 180
      },
      "tripPatterns": [
        {
          "startTime": "2020-09-26T07:56:47+02:00",
          "duration": 155893,
          "walkDistance": 354.371,
          "legs": [
            {
              "mode": "foot",
              "aimedStartTime": "2020-09-26T07:56:47+02:00",
              "aimedEndTime": "2020-09-26T08:00:00+02:00"
            },
            {
              "mode": "water",
              "line": {
                "id": "RB:TRO:Line:18_24"
              },
              "aimedStartTime": "2020-09-26T08:00:00+02:00",
              "aimedEndTime": "2020-09-26T09:40:00+02:00"
            },
            {
              "mode": "foot",
              "aimedStartTime": "2020-09-26T09:40:00+02:00",
              "aimedEndTime": "2020-09-26T09:41:32+02:00"
            },
            {
              "mode": "water",
              "line": {
                "id": "RB:HUR:Line:1"
              },
              "aimedStartTime": "2020-09-26T11:30:00+02:00",
              "aimedEndTime": "2020-09-28T03:15:00+02:00"
            }
          ]
        },
        {
          "startTime": "2020-09-26T07:45:00+02:00",
          "duration": 156600,
          "walkDistance": 0,
          "legs": [
            {
              "mode": "water",
              "line": {
                "id": "RB:HUR:Line:1"
              },
              "aimedStartTime": "2020-09-26T07:45:00+02:00",
              "aimedEndTime": "2020-09-28T03:15:00+02:00"
            }
          ]
        }
      ]
    }
  }
}

Observed behavior

In some cases PATH_NOT_FOUND is returned instead.

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

Latest dev-2.x

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

https://drive.google.com/file/d/1kSLRKe_cccPbNUBZ04Qstb6jpi7ccUX_/view?usp=sharing (Norway NeTEx file)
https://drive.google.com/file/d/1B1hsSb5IBqEZ97mFpsdJASIvx3mpBIZT/view?usp=sharing (Norway OSM)

Command line used to start OTP

--load [graph directory] --serve

Router config and graph build config JSON

Not used

Steps to reproduce the problem

Do the search specified above a few times. In some cases it will return PATH_NOT_FOUND.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days