Skip to content

Handle alerts for stations - #6750

Merged
leonardehrenfried merged 9 commits into
opentripplanner:dev-2.xfrom
Aubin-MaaS:station_alert
Aug 7, 2025
Merged

leonardehrenfried merged 9 commits into
opentripplanner:dev-2.xfrom
Aubin-MaaS:station_alert

Conversation

@miklcct

@miklcct miklcct commented Jul 10, 2025 •

Copy link
Copy Markdown
Contributor

Summary

Handle alerts for stations in GTFS-RT and the corresponding API

Issue

Fixes #6120

In particular, this should achieve the following from the GTFS GraphQL API:

  • Loading alerts for a station should return all alerts for that station in the GTFS-RT feed.
  • Loading alerts for a stop should return alerts for that stop, and for the parent station in the GTFS-RT feed.
  • Leg alerts for public transport will also include alerts for the stations used in the leg.

Unit tests

Integration tests are added into the GTFS GraphQL API

Documentation

None

Changelog

Needed

Bumping the serialization version id

Not needed

@codecov

codecov Bot commented Jul 10, 2025 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 80.00000% with 2 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (dev-2.x@27cb855). Learn more about missing BASE report.
⚠️ Report is 14 commits behind head on dev-2.x.

Files with missing lines Patch % Lines
...pis/gtfs/datafetchers/AlertEntityTypeResolver.java 0.00% 0 Missing and 1 partial ⚠️
...ntripplanner/apis/gtfs/datafetchers/AlertImpl.java 75.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             dev-2.x    #6750   +/-   ##
==========================================
  Coverage           ?   71.87%           
  Complexity         ?    19132           
==========================================
  Files              ?     2074           
  Lines              ?    77763           
  Branches           ?     7936           
==========================================
  Hits               ?    55890           
  Misses             ?    19064           
  Partials           ?     2809           

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

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@miklcct
miklcct marked this pull request as ready for review July 16, 2025 11:57
@miklcct
miklcct requested a review from a team as a code owner July 16, 2025 11:57
@leonardehrenfried

Copy link
Copy Markdown
Member

My first gut feeling is that this is the correct thing to do, but does the spec explicity talk about this?

@miklcct

miklcct commented Jul 16, 2025 •

Copy link
Copy Markdown
Contributor Author

My first gut feeling is that this is the correct thing to do, but does the spec explicity talk about this?

The spec does not limit the application of alerts to platforms / stations / corridors / entrances / etc. For example, you can set the affected entity to reference a stop_id which represents an entrance, and our TransitAlertService doesn't have such limitation as well (it does not have referential integrity).

In particular, "Loading alerts for a stop should return alerts for that stop, and for the parent station in the GTFS-RT feed." is open to discussion but there has already been a TODO for years in the code which I have been completed.

Also, I would like a reviewer on SIRI as well as I am not familiar to how multi-modal station works there.

@leonardehrenfried
leonardehrenfried merged commit f748dc1 into opentripplanner:dev-2.x Aug 7, 2025
t2gran pushed a commit that referenced this pull request Aug 7, 2025
@t2gran t2gran added this to the 2.8 (next release) milestone Aug 11, 2025
@miklcct
miklcct deleted the station_alert branch October 9, 2025 17:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Can't apply alert on a stop with location_type = 1 (station)

4 participants