Skip to content
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

Open
wants to merge 25 commits into
base: dev-2.x
Choose a base branch
from

Conversation

miklcct
Copy link
Contributor

@miklcct miklcct commented Nov 8, 2024

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, since null 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

@miklcct miklcct requested a review from a team as a code owner November 8, 2024 15:52
@miklcct miklcct force-pushed the fix-departureArrivalStopTime-npe branch from 36ef65d to ed3bb9b Compare November 8, 2024 15:53
Copy link

codecov bot commented Nov 8, 2024

Codecov Report

Attention: Patch coverage is 63.38028% with 26 lines in your changes missing coverage. Please review.

Project coverage is 69.94%. Comparing base (cbdb640) to head (4e542a7).
Report is 68 commits behind head on dev-2.x.

Files with missing lines Patch % Lines
...java/org/opentripplanner/model/TripTimeOnDate.java 9.09% 3 Missing and 7 partials ⚠️
...entripplanner/apis/gtfs/datafetchers/TripImpl.java 87.09% 3 Missing and 1 partial ⚠️
...model/model/timetable/DatedServiceJourneyType.java 0.00% 4 Missing ⚠️
...transmodel/model/timetable/ServiceJourneyType.java 20.00% 4 Missing ⚠️
...planner/transit/service/DefaultTransitService.java 80.00% 3 Missing and 1 partial ⚠️
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.
📢 Have feedback on the report? Share it here.

@miklcct miklcct force-pushed the fix-departureArrivalStopTime-npe branch 3 times, most recently from 428a549 to df345c2 Compare November 8, 2024 16:08
@miklcct miklcct force-pushed the fix-departureArrivalStopTime-npe branch from 39ca3c3 to d3d283f Compare November 14, 2024 18:32
@miklcct
Copy link
Contributor Author

miklcct commented Nov 23, 2024

I am going to wait for #5393 first.

# 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
@leonardehrenfried
Copy link
Member

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
@optionsome optionsome removed their request for review December 19, 2024 14:05
@leonardehrenfried leonardehrenfried added the Real-Time Update The issue/PR is related to RealTime updates label Jan 9, 2025
Timetable timetable = findTimetable(pattern, serviceDate);

// If realtime moved pattern back to original trip, fetch it instead
if (timetable.getTripIndex(trip.getId()) == -1) {
Copy link
Contributor

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) {
Copy link
Contributor

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) {
Copy link
Contributor

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);
Copy link
Contributor

@vpaturet vpaturet Jan 20, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Real-Time Update The issue/PR is related to RealTime updates
Projects
None yet
4 participants