You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We realized that after adding a new gtfs file to our OTP instance, with trips with frequencies (besides scheduled times), the calls to graphQL "stoptimes" were returning 500.
To be sure of this, we removed the frequencies.txt file and the issue disappeared (of course we didn’t had results for the period where frequencies were applied).
We tried this on both “prod” and “latest” docker images.
Another thing we noticed, whilst using the file with frequencies, was that:
When using OTP builtin webinterface, we were able to see results
When using digitransit (whose requests go through graphql) we were not
With further debug, it was found that the call to get stoptimes would work only with scheduledTimetable:
@@ -1800,9 +1804,30 @@
.name("stoptimes")
.description("List of times when this trip arrives to or departs from a stop")
.type(new GraphQLList(stoptimeType))
.dataFetcher(environment -> TripTimeShort.fromTripTimes(
index.patternForTrip.get((Trip) environment.getSource()).scheduledTimetable, # HERE!
environment.getSource()))
In this situation, OTP throws the following:
otp_1 | 18:40:40.356 WARN (ExecutionStrategy.java:70) Exception while fetching data
otp_1 | java.lang.ArrayIndexOutOfBoundsException: null
otp_1 | 18:40:40.357 WARN (FieldErrorInstrumentation.java:174) Exception while fetching field
otp_1 | java.lang.ArrayIndexOutOfBoundsException: null
otp_1 | 18:40:40.409 WARN (ExecutionStrategy.java:70) Exception while fetching data
otp_1 | java.lang.ArrayIndexOutOfBoundsException: null
otp_1 | 18:40:40.411 WARN (FieldErrorInstrumentation.java:174) Exception while fetching field
otp_1 | java.lang.ArrayIndexOutOfBoundsException: null
otp_1 | 18:40:40.429 WARN (FieldErrorInstrumentation.java:133) Errors executing query
That's because the Trip didn't had a "scheduledTimetable".
So we've implement a fix. Its been working for some time an we believe its ok:
.name("stoptimes")
.description("List of times when this trip arrives to or departs from a stop")
.type(new GraphQLList(stoptimeType))
.dataFetcher(environment ->{
Timetable timetable = index.patternForTrip.get((Trip) environment.getSource()).scheduledTimetable;
// If the Trip is frequency-based, there are no scheduled tripTimes (they must com from <FrequencyEntry>.tripTimes)
if (timetable.tripTimes.isEmpty()) {
// This should probably be encapsulated into a function named TripTimeShort.fromFrequencyTripTimes,
// since it does the same as existing function TripTimeShort.fromTripTimes, but for Frequency.
// Or, it could also be moved into TripTimeShort.fromTripTimes.
List<TripTimeShort> out = Lists.newArrayList();
for (FrequencyEntry freq : timetable.frequencyEntries) {
TripTimes times = freq.tripTimes;
for (int i = 0; i < times.getNumStops(); ++i) {
out.add(new TripTimeShort(times, i, timetable.pattern.getStop(i), null));
}
}
return out;
} else {
return TripTimeShort.fromTripTimes(timetable, environment.getSource());
}
})
.build())
```
We're grad to share it via patch or pull request.
The text was updated successfully, but these errors were encountered:
Hey @optionsome, i believe the commit in this PR is not perfect for merge, but i would kindly appreciate some comments on the PR itself or the issue.
Cheers
We realized that after adding a new gtfs file to our OTP instance, with trips with frequencies (besides scheduled times), the calls to graphQL "stoptimes" were returning 500.
To be sure of this, we removed the frequencies.txt file and the issue disappeared (of course we didn’t had results for the period where frequencies were applied).
We tried this on both “prod” and “latest” docker images.
Another thing we noticed, whilst using the file with frequencies, was that:
With further debug, it was found that the call to get stoptimes would work only with scheduledTimetable:
In this situation, OTP throws the following:
That's because the Trip didn't had a "scheduledTimetable".
So we've implement a fix. Its been working for some time an we believe its ok:
The text was updated successfully, but these errors were encountered: