Repository navigation
feat(GroupFilter): Propogate CR Delays to downstream stops - #449
Conversation
| existing_stu != nil -> | ||
| [existing_stu] | ||
|
|
||
| !is_nil(departure) && now > departure && stop_sequence > first_stop_sequence -> |
There was a problem hiding this comment.
note: I don't compare stop_ids anywhere and am only relying on stop_sequence. Is that safe?
There was a problem hiding this comment.
I think it's fine! The combination of trip ID (these are all from the same trip) and stop sequence should uniquely identify the schedule departure.
There was a problem hiding this comment.
Great, I have a vague memory of something about virtual vs physical platforms for CR which I why I was hoping to avoid it in the first place.
There was a problem hiding this comment.
Ah, right, I had forgotten about the parent vs. child stop thing entirely but that is indeed a good reason for relying just on stop sequence.
…matching_statuses
8cbd38b to
46cdbdd
Compare
| {Concentrate.GroupFilter.SuppressStopTimeUpdate, terminal_suppression_by_time: %{}} | ||
| {Concentrate.GroupFilter.SuppressStopTimeUpdate, terminal_suppression_by_time: %{}}, | ||
| {Concentrate.GroupFilter.PropogateDownstreamDelays, | ||
| matching_statuses: ["Delayed"], downstream_status: "Delayed"} |
There was a problem hiding this comment.
TODO: Get complete list of relevant statuses.
There was a problem hiding this comment.
@lemald I updated the status list to re-use the config from boarding_status_override based on the given list. My one concern is that both "PRIORITY" and "HOLD" Statuses are converted to "Info to follow". Any concerns about this logic applying to "PRIORITY" too?
Since the conversion of boarding_status_override is done at the parsing level I think it would be a bigger but not horrible effort to change (maybe just a new filer at the end). But if the user-facing string is the same, I'm wondering if it would be acceptable to treat them as the same for the purpose of downstream delays.
There was a problem hiding this comment.
Yeah, I think that's probably fine, especially since I'm guessing that PRIORITY and HOLD are less-frequently-used statuses.
lemald
left a comment
lemald
left a comment
There was a problem hiding this comment.
Okay, I think this looks good! It sounds like before merging and going to prod we'll want to:
- Confirm the list of statuses for which this should apply (already noted).
- Deploy to a dev environment and test out there.
GitHub Actions
Inactive
GitHub Actions
Error
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
Summary of changes
Asana Ticket: CR Delays | Concentrate change to propagate status when delays
This adds a new GroupFilter to propagate delay StopTimeUpdates under certain circumstances:
Tested with unit tests and end-to-end in dev-green.
Note: I used AI for autocompleting helper functions and generating test stubs.