Skip to content

feat: removing 120 min limit cutoff#1823

Open
thedecaftony wants to merge 1 commit into
mainfrom
tl-remove-120-min-cutoff-limit
Open

feat: removing 120 min limit cutoff#1823
thedecaftony wants to merge 1 commit into
mainfrom
tl-remove-120-min-cutoff-limit

Conversation

@thedecaftony

@thedecaftony thedecaftony commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

Summary

Ticket: Nearby - remove 120 min cutoff

What is this PR for?
Removing the 120 min limit cutoff for trips that are schedule over 120 minutes can be displayed in the app

iOS

  • If you added any user-facing strings on iOS, are they included in Localizable.xcstrings?
    • Add temporary machine translations, marked "Needs Review"

android

  • All user-facing strings added to strings resource in alphabetical order
  • Expensive calculations are run in withContext(Dispatchers.Default) where possible (ideally in shared code)

Testing

What testing have you done?

  • Unit testing
  • Checked that trips schedules over 120 min were visible
  • Shared finding with the team in slack
Before After
Screenshot_20260625_134916 Screenshot_20260625_120253
Screenshot_20260625_133943 Screenshot_20260625_134132

@thedecaftony thedecaftony requested a review from a team as a code owner June 29, 2026 17:27
@thedecaftony thedecaftony requested a review from KaylaBrady June 29, 2026 17:27
typicality = RoutePattern.Typicality.Typical
representativeTrip { headsign = "Typical Out" }
}
// should not be included because not typical and prediction beyond 120 minutes

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: this comment should be updated as well to reflect that it should be shown (or the comment can just be removed)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right, I'll update it

val predictionPastPrediction =
objects.prediction {
stopId = stop1.id
stopId = stop2.id

@KaylaBrady KaylaBrady Jun 30, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: I think it is important that this is stop1 so that we can assert that predictions for this stop in the past are not shown. I do think there is an important comparison against now that we need to preserve to ensure past predictions are filtered out (and I'm wondering now how there isn't an existing user facing issue on StopDetailsFiltered and Favorites where cutoff time is already null 🤔)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to revisit this, I was running on the assumption that this code was running after my change, but it shouldn't.

I thought that the reason why this was showing up was because the stopId in the prediction was the same as in the vehicleId. I guess after my change validation is gone and it would show predictions in the past that don't match prediction.stopId == vehicle.stopId

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.

2 participants