feat: New get_endpoints function for alert endpoints in Subway Status

[robbie-sundstrom]

Asana task: Update Subway Status to deal with GL combined stops being closed

Creates a new get_endpoints function used by the subway_status widget to determine the names for the endpoints of alerts.

• This is inspired by and directly takes some code in the the dotcom repo for their subway status widget - specifically working with the UnrootedPolytree data structure
• Note that a follow up to this could move the reconstructed alert widget to use this get_endpoints function as well

• Tests added?

[deanshi]

Still parsing some of the PolyTree stuff and comparing with the dotcom work, but some small questions in the meantime.

[deanshi]

Do we need this filter check?

I feel like I'm just missing an edge case but are there cases where the Alert itself, after filtering for the route, will have stops that don't exist in stop_sequence (which to my understanding is just a huge map of all of the stops to being with).

[robbie-sundstrom]

Good question! The reason it's structured this way is because there are IDs in ie_stops that aren't associated with a boarding location. This is encoded in location_type of the stop, but we don't get that information from the API within the informed_entities of an alert. Starting with the stop_sequence and then narrowing down to IDs included in the alert is a way to make sure that we only include the boarding locations.

Looking back at this function it is a bit confusing, so I will at least add a comment here the next time I'm updating it before merging.

[digitalcora]

This is encoded in location_type of the stop, but we don't get that information from the API within the informed_entities of an alert.

Drive-by comment, but we very much could if we wanted to! We already do something like this for Facilities; you'll note the facility field of an informed entity is the entire Facility struct, not just a facility ID. The reason this isn't a trivial change is because of all the existing places in the code that assume the stop field is only a stop ID rather than a struct, and tracking down all these places is tricky because there is no proper InformedEntity struct that would be legible to the LSP/compiler, they're just anonymous maps (there is also no good reason for this, and I strongly believe it should change).

As always, there is not strictly a need to address this here. But I think this is maybe the third or fourth time this exact issue has come up within the past year, so I'm feeling like it should at least be translated into a refactor task to be discussed and estimated in Asana.

[robbie-sundstrom]

Agreed, it seems like this comes up almost every time we are adding an alert related feature. I created an Asana task for that refactor we could discuss tomorrow

[deanshi]

Double checked on dev-green and it's looking good.