Fix trip references when includeTrip is false#1101
Conversation
Per the OneBusAway spec (Extension 4c), setting includeTrip=false should omit only the main trip record from references.trips, while still including the preceding and following block trips when includeSchedule=true. Previously the entire reference-resolution block was nested inside the if params.IncludeTrip condition, so disabling includeTrip skipped block-trip resolution entirely and returned an empty references.trips array. Move the main trip ID into tripsToInclude only when includeTrip is true, while always appending the next, previous, and active trips based on includeSchedule and includeStatus. Update and add tests to verify block trips remain referenced while the main trip is omitted.
|
Warning Review limit reached
More reviews will be available in 35 minutes and 43 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesReferenced Trip Aggregation Fix
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
internal/restapi/trip_details_handler_test.go (1)
174-192: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winConsider asserting that test data includes block trips to prevent vacuous pass.
If the test fixture returned by
mustGetTriphas no preceding/following trips,expectedBlockTripswill be empty and the finalforloop (lines 189-192) won't execute any assertions. The test would pass without actually verifying the fix.💡 Suggested assertion
for _, refTrip := range withTrip.Data.References.Trips { if refTrip.ID != tripID { expectedBlockTrips[refTrip.ID] = true } } + + // Ensure test data actually has block trips to verify. + assert.NotEmpty(t, expectedBlockTrips, + "test fixture should include preceding/following trips to meaningfully test this behavior")🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/restapi/trip_details_handler_test.go` around lines 174 - 192, The test could pass vacuously if the test fixture from mustGetTrip contains no block trips, since expectedBlockTrips would be empty and the final for loop validating block trips would not execute any assertions. Add an assertion after building expectedBlockTrips to verify it is not empty, ensuring the test fixture actually contains block trips and the test is meaningful.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@internal/restapi/trip_details_handler_test.go`:
- Around line 174-192: The test could pass vacuously if the test fixture from
mustGetTrip contains no block trips, since expectedBlockTrips would be empty and
the final for loop validating block trips would not execute any assertions. Add
an assertion after building expectedBlockTrips to verify it is not empty,
ensuring the test fixture actually contains block trips and the test is
meaningful.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 27a08dcb-112f-4c2b-be6e-9a2a797dc979
📒 Files selected for processing (2)
internal/restapi/trip_details_handler.gointernal/restapi/trip_details_handler_test.go
Add an assertion to ensure expectedBlockTrips is not empty. This prevents a vacuous pass if the test fixture lacks preceding or following trips.
|



Summary
Fixes the trip-details endpoint so that includeTrip=false correctly
omits the main trip from references.trips while preserving the
preceding and following block trips (when includeSchedule=true), as
required by OneBusAway spec Extension 4c.
Problem
In tripDetailsHandler, the logic to resolve preceding/following
block trips was nested entirely inside the
if params.IncludeTripblock. As a result, requesting includeTrip=false skipped the whole
reference-resolution path and produced an empty references.trips
array, even when includeSchedule=true.
Changes
the active trip (when includeStatus=true), regardless of the
includeTrip value.
trip is excluded rather than expecting an empty list.
block trips are still referenced when includeTrip=false.
Closes: #1087
Summary by CodeRabbit