-
Notifications
You must be signed in to change notification settings - Fork 3
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
fix: filter stop time updates without arrival/departure #294
Conversation
Coverage of commit
|
Coverage of commit
|
Coverage of commit
|
Coverage of commit
|
Coverage of commit
|
Coverage of commit
|
Coverage of commit
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you want to that at this stage. Commuter Rail predictions can exist without an arrival or departure time, but with a boarding_status
.
Instead, I'd look at filtering these out of non-enhanced outputs, as those wouldn't include the boarding_status
field.
Ugh, and in fact they already are being filtered from non-enchanced feeds (https://github.com/mbta/concentrate/blob/master/lib/concentrate/encoder/trip_updates.ex#L28). But the predictions API uses the enhanced feed and so is publishing a bunch of nonsensical bus predictions. I'll need to come up with a new idea to deal with those. Especially since apparently similar predictions are valid in other contexts. |
Given the original report, it looks like the issue is starting with Busloc. That application should never be generating predictions without at least one of an arrival/departure time AFAIK. |
As far as I can tell, it'll never output an arrival/departure time. Some waivers it publishes as skipped, some as scheduled (https://github.com/mbta/busloc/blob/master/lib/busloc/waiver/encoder/trip_updates_enhanced.ex#L71). The last time we went down this rabbit-hole we were unable to get a clear answer as to the purpose of the scheduled updates. |
Right right, this is coming back to me now. Maybe filtering out STUs without a time OR boarding status would work? |
That seems reasonable. I'll make the change. Thanks! |
Coverage of commit
|
def filter(%StopTimeUpdate{} = stu) do | ||
scheduled? = | ||
StopTimeUpdate.schedule_relationship(stu) == :SCHEDULED || | ||
StopTimeUpdate.schedule_relationship(stu) == nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: is it possible for this to be nil
? I thought the parser converted it to the default value of :SCHEDULED
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like your correct, I've removed the condition. I was working off the spec and the fact that concentrate will omit schedule_relationship
in it's output if it's :SCHEDULED
Coverage of commit
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍰
code looks good! can you deploy again to make sure it's working okay?
Yep! I sent it to dev-green, I'll keep an eye on it for issues. |
Summary of changes
Asana Ticket: 🐛 API publishing bus predictions with no times or schedule relationship
This filters out StopTimeUpdates which are scheduled, but have no arrival/departure. These occur when the BusLoc feed contains stops which Swiftly either isn't yet predicting, or is no longer publishing predictions for because the bus is already well past that stop.