Refetch transit leg with a leg query of GTFS GraphQL API

[vesameskanen]

Summary

GTFS leg object now includes a graphql node id . Transit leg can be refetched using a new leg query:

query legQuery { leg(id: "foo") { mode start { estimated { time } } } }

Such query can be used to update an itinerary and to detect if the itinerary is no longer possible because of delays or canceled trips.

Non-transit legs cannot be refetched - the response is always null.

This PR also adds missing implementation for querying leg's realtimeState via GTFS graphql API.

Documentation

In the graphql schema.

[leonardehrenfried]

@binh-dam-ibigroup This might be interesting for you.

@vesameskanen I almost cannot believe that it is so easy!

[codecov]

Codecov Report

Attention: Patch coverage is 48.14815% with 14 lines in your changes missing coverage. Please review.

Project coverage is 69.83%. Comparing base (c022422) to head (857b815).
Report is 71 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
...pplanner/apis/gtfs/datafetchers/QueryTypeImpl.java	12.50%	7 Missing ⚠️
...ntripplanner/apis/gtfs/generated/GraphQLTypes.java	0.00%	7 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6045      +/-   ##
=============================================
+ Coverage      69.81%   69.83%   +0.01%     
- Complexity     17418    17460      +42     
=============================================
  Files           1974     1975       +1     
  Lines          74537    74624      +87     
  Branches        7633     7638       +5     
=============================================
+ Hits           52040    52115      +75     
- Misses         19847    19857      +10     
- Partials        2650     2652       +2     

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

[optionsome]

@vesameskanen I almost cannot believe that it is so easy!

This is easy because this was already done in the transmodel API. However, the transmodel API has own legs query for this because it lacks the node query/interface.

[optionsome]

@vesameskanen will still add some integration tests for this.

[vesameskanen]

GTFS integration tests currently cannot test leg refetching, because mocked itineraries lack essential data used in encoding the leg information. Integration test now tests only that legs contain the id.

[vesameskanen]

I tested new legs with relay and got lots of problems. Relay does not accept nodes with same node id but different content. Either all leg types must be serialized to unique id ('NotAvailable' is not OK), or we have to revert node interface for legs and add a dedicated leg query. Any opinions?

[leonardehrenfried]

Maybe I don't get it but don't all legs have the same type in GraphQL?

[optionsome]

Maybe I don't get it but don't all legs have the same type in GraphQL?

@vesameskanen explained to me that the issue is that the non-transit legs all have the same id. We discussed this today and thought maybe the solution would be to generate unique ids based on actual leg data (such as departure/arrival time) even if we don't support refetching based on those ids.

I tried adding tests for refetching the legs through the node query in the graphql integration tests on Tuesday but creating/maintaining such test would be slightly difficult.

[optionsome]

We might need to discuss my suggestion in a developer meeting. Idk if we should give entities global ids even if they are not refetchable with a node query. I think at least in netex, the ids are always unique and have the type in the id (if I'm not mistaken).

[optionsome]

I don't think we should use the global id anymore, since we have own query for this now, we can just return a string which is the output of the LegReferenceSerializer.encode(ref).

[vesameskanen]

Using plain string is indeed simpler. Changed.

[optionsome]

I think since the leg reference has "SCHEDULED_TRANSIT_LEG_V3" in the id (example base64 decoded id ��wh��SCHEDULED_TRANSIT_LEG_V3��HSL:3002Y_20240801_To_1_1223� 2024-09-26����������HSL:1174504��HSL:2611502��), I don't think it's necessary to prefix the id with "Leg" but since it's a small effort, we can still discuss this in the dev meeting.

[optionsome]

We decided to just use the LegReferenceSerializer.encode(ref) as is instead of encoding it again with the relay library. The id can be a String in the schema.

[leonardehrenfried]

I just realised that this doesn't use a proper mapper, which I think is a very useful thing.

Since I already approved, I wrote the code myself: leonardehrenfried@a763bc5

If you want you can cherry pick it into this PR.

[leonardehrenfried]

Ah, too late. I will open another one myself.

[miklcct]

My GTFS has an original_trip_id in addition to trip_id. If there is a timetable change affecting only a few days in the original calendar, a new trip_id has to be generated because it must be unique, however the original_trip_id field is the same.

In this case, can it be used to fetch the updated timetable?