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

Reject SIRI messages with invalid stops and missing times #6499

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

Conversation

vpaturet
Copy link
Contributor

@vpaturet vpaturet commented Feb 27, 2025

Summary

This PR applies strictly the validation rules specified in the Nordic SIRI profile.
In particular:

  • A SIRI-ET message must contain recorded or estimated times for all stops.
  • A SIRI-ET message cannot refer to an unknown stop.
  • A SIRI-ET message that updates an existing trip cannot replace a stop by another stop unless they belong to the same station.

This PR ensures that messages that fail these validation rules are rejected.
As a consequence, the time interpolation logic is not used anymore and can be removed .

The rules are relaxed for full trip cancellation: a message is accepted even if it contains incomplete times or invalid stops.

Issue

No

Unit tests

Updated unit tests.

Documentation

No

@vpaturet vpaturet added the Real-Time Update The issue/PR is related to RealTime updates label Feb 27, 2025
Copy link

codecov bot commented Feb 27, 2025

Codecov Report

Attention: Patch coverage is 81.39535% with 8 lines in your changes missing coverage. Please review.

Project coverage is 70.18%. Comparing base (04fadbf) to head (36ed324).
Report is 14 commits behind head on dev-2.x.

Files with missing lines Patch % Lines
...planner/updater/trip/siri/ModifiedTripBuilder.java 79.48% 6 Missing and 2 partials ⚠️
Additional details and impacted files
@@              Coverage Diff              @@
##             dev-2.x    #6499      +/-   ##
=============================================
- Coverage      70.20%   70.18%   -0.02%     
+ Complexity     18313    18309       -4     
=============================================
  Files           2080     2081       +1     
  Lines          77182    77197      +15     
  Branches        7831     7832       +1     
=============================================
- Hits           54183    54181       -2     
- Misses         20230    20249      +19     
+ Partials        2769     2767       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@vpaturet vpaturet force-pushed the reject_siri_messages_with_invalid_stops branch from ab30c6a to 02cf113 Compare February 28, 2025 09:29
import org.opentripplanner.updater.trip.TripInput;
import org.opentripplanner.updater.trip.siri.SiriEtBuilder;

class IncompleteMessageTest implements RealtimeTestConstants {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Back when I started adding these module tests @t2gran asked me to put these into packages to group them by feature. If you like this pattern, can you put this one into the package rejection?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

result.failureValue().errorType(),
invalidStopIndex
);
return result.toFailureResult();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

create a new result with trip id and datasource

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@vpaturet vpaturet marked this pull request as ready for review March 3, 2025 17:32
@vpaturet vpaturet requested a review from a team as a code owner March 3, 2025 17:32
@@ -424,132 +434,6 @@ void testUpdateUpdatedStop() {
assertEquals(RealTimeState.MODIFIED, updatedTimes.getRealTimeState());
}

@Test
void testUpdateCascading() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests just test something that we have now removed, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, testUpdateCascading assumes that we accept a message with fewer calls than in the scheduled trip. We now refuse these messages except for full cancellation, and full cancellation is tested elsewhere.
testCreateStopPatternNoCalls and testCreateStopPatternSingleCall call ModifiedTripBuilder.createStopPattern with preconditions that are now impossible.

@@ -268,10 +281,13 @@ static StopPattern createStopPattern(
alreadyVisited.add(call);
break;
}
if (!matchFound) {
return Result.failure(new UpdateError(null, STOP_MISMATCH, i));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will fail with this error if there is a missing call as well. I guess that's not a big probeblem but it seems like an inaccurate error code for that case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added validation rules for too few and too many calls.

@@ -242,16 +249,22 @@ static StopPattern createStopPattern(
for (int i = 0; i < numberOfStops; i++) {
StopLocation stop = builder.stops.original(i);

boolean matchFound = false;
for (CallWrapper call : calls) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic in this method will still accept if there are too many calls in the ET update. Maybe fixing that is part of your other extra-call-PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added validation rules for too few and too many calls.

@@ -551,7 +551,7 @@ void testAddedTripFailOnUnknownStop() {

assertTrue(addedTrip.isFailure(), "Trip creation should fail");
assertEquals(
UpdateError.UpdateErrorType.NO_VALID_STOPS,
UpdateError.UpdateErrorType.UNKNOWN_STOP,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a test for UNKNOWN_STOP here but perhaps you could add one for regular, non-extra-journey updates.

Copy link
Contributor Author

@vpaturet vpaturet Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added unit tests for unknown stop and stop mismatch

vpaturet added 3 commits March 4, 2025 15:56
# Conflicts:
#	application/src/test/java/org/opentripplanner/updater/trip/siri/ModifiedTripBuilderTest.java
#	application/src/test/java/org/opentripplanner/updater/trip/siri/moduletests/InterpolationTest.java
* Full cancellation of a trip.
*/
private Result<TripUpdate, UpdateError> cancelTrip(RealTimeTripTimes newTimes) {
LOG.debug("Trip is cancelled");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pretty useless log message, isn't it? I think you should either add the trip id or remove it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty useless indeed. I've removed it.

@vpaturet vpaturet added Entur Test This is currently being tested at Entur Improvement A functional improvement and removed Entur Test This is currently being tested at Entur labels Mar 5, 2025
@@ -242,16 +253,22 @@ static StopPattern createStopPattern(
for (int i = 0; i < numberOfStops; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a line of documentation in both createStopPattern() and applyUpdates() that the number of calls are guaranteed to be the same as the numberOfStops. I think that will make it easier to if we decide to refactor this code in the future.

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

Successfully merging this pull request may close these issues.

3 participants