-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix stop time fetching in added or replacement trips #6245
base: dev-2.x
Are you sure you want to change the base?
Fix stop time fetching in added or replacement trips #6245
Conversation
36ef65d
to
ed3bb9b
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #6245 +/- ##
=============================================
+ Coverage 69.85% 69.94% +0.09%
- Complexity 17920 17948 +28
=============================================
Files 2035 2034 -1
Lines 76495 76494 -1
Branches 7824 7826 +2
=============================================
+ Hits 53433 53503 +70
+ Misses 20325 20241 -84
- Partials 2737 2750 +13 ☔ View full report in Codecov by Sentry. |
428a549
to
df345c2
Compare
df345c2
to
38c3a5a
Compare
It has nothing to do with routing and belongs to the wrong package
better to let error propagate
it can be empty if the trip doesn't run at all
39ca3c3
to
d3d283f
Compare
application/src/main/java/org/opentripplanner/transit/service/TransitService.java
Show resolved
Hide resolved
application/src/main/java/org/opentripplanner/transit/service/TransitService.java
Show resolved
Hide resolved
application/src/main/java/org/opentripplanner/transit/service/DefaultTransitService.java
Show resolved
Hide resolved
application/src/test/java/org/opentripplanner/apis/gtfs/GraphQLIntegrationTest.java
Outdated
Show resolved
Hide resolved
I am going to wait for #5393 first. |
# Conflicts: # application/src/test/java/org/opentripplanner/transit/service/DefaultTransitServiceTest.java
# Conflicts: # application/src/main/java/org/opentripplanner/apis/gtfs/datafetchers/TripImpl.java # application/src/main/java/org/opentripplanner/apis/transmodel/model/timetable/ServiceJourneyType.java # application/src/main/java/org/opentripplanner/routing/TripTimeOnDateHelper.java # application/src/main/java/org/opentripplanner/transit/service/TransitService.java
application/src/main/java/org/opentripplanner/updater/trip/TimetableSnapshotSource.java
Outdated
Show resolved
Hide resolved
application/src/main/java/org/opentripplanner/transit/service/DefaultTransitService.java
Show resolved
Hide resolved
application/src/test/java/org/opentripplanner/updater/trip/TripUpdateBuilder.java
Outdated
Show resolved
Hide resolved
Please resolve the conflicts. |
# Conflicts: # application/src/test/java/org/opentripplanner/apis/gtfs/GraphQLIntegrationTest.java # application/src/test/java/org/opentripplanner/transit/service/DefaultTransitServiceTest.java # application/src/test/resources/org/opentripplanner/apis/gtfs/expectations/patterns.json
application/src/test/java/org/opentripplanner/updater/trip/TripUpdateBuilder.java
Outdated
Show resolved
Hide resolved
Timetable timetable = findTimetable(pattern, serviceDate); | ||
|
||
// If realtime moved pattern back to original trip, fetch it instead | ||
if (timetable.getTripIndex(trip.getId()) == -1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check was a workaround/fallback for a bug that has been fixed recently when refactoring TimetableSnapshot. I would rather remove this. If the bug is reintroduced it will fail hard with an NPE in the same method and that will be easy to catch.
Non-blocking for this PR, I can do it in a follow-up PR.
public static List<TripTimeOnDate> fromTripTimes( | ||
Timetable table, | ||
Trip trip, | ||
LocalDate serviceDate, | ||
Instant midnight | ||
) { | ||
TripTimes times = table.getTripTimes(trip); | ||
if (times == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any code path that leads to this condition after your fix is applied?
(I do not see any unit test that touches this line)
public static List<TripTimeOnDate> fromTripTimes(Timetable table, Trip trip) { | ||
TripTimes times = table.getTripTimes(trip); | ||
if (times == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any code path that leads to this condition after your fix is applied?
(I do not see any unit test that touches this line)
@@ -96,6 +101,47 @@ public DefaultTransitService( | |||
this.timetableSnapshot = timetableSnapshotBuffer; | |||
} | |||
|
|||
@Override | |||
public Optional<List<TripTimeOnDate>> getScheduledTripTimes(Trip trip) { | |||
TripPattern tripPattern = findPattern(trip); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the javadoc, TransitService#findPattern(Trip) should not return null, even for an added trip:
Return the scheduled trip pattern for a given trip.
If the trip is an added trip (extra journey), return the initial trip pattern for this trip.
When an added trip is submitted to TimetableSnapshot
, it should be registered in the index TimetableSnapshot.realTimeAddedPatternForTrip
. DefaultTransitService#findPattern(Trip)
queries this index to return the pattern of an added trip.
In the case of the SIRI updater, there is logic in AddedTripBuilder
that ensures that the flag RealTimeTripUpdate.tripCreation
is set, and this guarantees that the realTimeAddedPatternForTrip
index is updated in TimetableSnapshot
.
It seems this logic is missing in the case of the GTFS updater.
Since we aim at minimizing the differences between the SIRI updater and the GTFS updater, we should probably apply the logic present in the SIRI updater to the GTFS updater.
Summary
This fixes problems when reading stop times for added or replacement trips.
The logic of fetching trip times is moved into
TransitService
. The list is optional because it can be empty if the trip doesn't run at all on a specified date (in contrast, an empty list would theoretically mean that the trip does run on the date, but it doesn't make any call for the whole journey).Also, the behaviour of invalid date is changed to produce an error instead of returning
null
silently in the GTFS GraphQL API, sincenull
is a valid return value meaning the trip doesn't run.Issue
Fixes #6088
Fixes #6242
Unit tests
Unit tests are added into
TransitService
for the new methods, for both existing and added trips.GraphQL Integration tests are added for one added trip and one replacement trip. This is the first time real-time updates can be integration tested.
Documentation
None needed