feat: Implement arrivals-and-departures-for-location endpoint#787
feat: Implement arrivals-and-departures-for-location endpoint#787ARCoder181105 wants to merge 31 commits into
Conversation
ARCoder181105
changed the title
arrivals-and-departures-for-location endpoint
ARCoder181105
changed the title
arrivals-and-departures-for-location endpointPort Java arrivals-and-departures-for-location to Go maglev architecture. - Geospatial stop lookup via in-memory R-tree index - 3-day window queries (yesterday/today/tomorrow) for overnight trip support - Batch-fetch routes/trips/stop-times to avoid N+1 queries - Deduplicated references block (Agencies, Routes, Stops, Trips, Situations) - nearbyStopIds via haversine distance, excluding stops already in stopIds - arrivalStatus derived from schedule deviation (LATE/EARLY/ON_TIME/default) - limitExceeded flag honoring maxCount (mirrors Java MaxCountSupport) - Add StopWithDistance model and NewArrivalsAndDeparturesForLocationResponse - Add ORDER BY to GetAgenciesForStops for deterministic results - Fix nil vehicle passed to BuildTripStatus in arrivals_and_departure_for_stop.go - Register GET /api/where/arrivals-and-departures-for-location.json - Add unit, E2E, and context cancellation tests Closes OneBusAway#787 Fixes OneBusAway#799
ARCoder181105
force-pushed
the
feature/arrivals-departures-for-location
branch
from
e3c9b4d to
b056442
Compare
|
Hey @ARCoder181105 Great work on this endpoint! |
|
Hi @3rabiii, thanks for the review! I have implemented the missing parameters you mentioned ( I also addressed a few other minor parity gaps (added Everything has been tested and verified against the live PugetSound schema. Ready for another look whenever you have time! |
|
Hi @aaronbrethorst , @Ahmedhossamdev The PR is ready for review ... |
|
Hi @ARCoder181105 |
|
@Ahmedhossamdev I already updated it here #807 |
Port Java arrivals-and-departures-for-location to Go maglev architecture. - Geospatial stop lookup via in-memory R-tree index - 3-day window queries (yesterday/today/tomorrow) for overnight trip support - Batch-fetch routes/trips/stop-times to avoid N+1 queries - Deduplicated references block (Agencies, Routes, Stops, Trips, Situations) - nearbyStopIds via haversine distance, excluding stops already in stopIds - arrivalStatus derived from schedule deviation (LATE/EARLY/ON_TIME/default) - limitExceeded flag honoring maxCount (mirrors Java MaxCountSupport) - Add StopWithDistance model and NewArrivalsAndDeparturesForLocationResponse - Add ORDER BY to GetAgenciesForStops for deterministic results - Fix nil vehicle passed to BuildTripStatus in arrivals_and_departure_for_stop.go - Register GET /api/where/arrivals-and-departures-for-location.json - Add unit, E2E, and context cancellation tests Closes OneBusAway#787 Fixes OneBusAway#799
…dpoint - Add parsing and handling for emptyReturnsNotFound parameter - Add parsing and GTFS filtering for routeType parameter - Add frequencyMinutesBefore and frequencyMinutesAfter parsing - Fix nearbyStopIds logic to match Java's includeInputIdsInNearby=true override
…stopSequence offset in arrivals-and-departures-for-location
ARCoder181105
force-pushed
the
feature/arrivals-departures-for-location
branch
from
e4feabe to
4c74707
Compare
|
Warning Review limit reached
Your plan currently allows 1 review/hour. Refill in 38 minutes and 15 seconds. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more review capacity refills, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than trial, open-source, and free plans. In all cases, review capacity refills continuously over time. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (18)
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR implements the ChangesArrivals-and-Departures-for-Location Endpoint
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes The PR introduces a substantial new endpoint (1120 lines of core logic) with diverse functionality: parameter validation, spatial/temporal queries, batch database operations, trip status and alert aggregation, reference deduplication, and vehicle position inference. While changes are well-structured across coherent checkpoints, the density of algorithmic logic, cross-file behavioral updates, and test coverage span requires careful review of each integration point. Possibly related issues
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
internal/restapi/context_cancellation_test.go (1)
84-95:429as an allowed outcome may dilute cancellation-signal quality.Because all sub-tests reuse the same API/rate limiter, a rate-limit hit can pass this assertion without validating context-cancel handling. Consider isolating limiter state per sub-test (fresh API/mux) for this suite.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/restapi/context_cancellation_test.go` around lines 84 - 95, The test currently allows HTTP 429 as an acceptable response which can mask failures in context-cancellation handling because all sub-tests share the same rate limiter; update the test to initialize a fresh API/mux (and its rate limiter) for each sub-test so limiter state is isolated, and remove http.StatusTooManyRequests from the accepted status list in the assertion; specifically, change the sub-test setup to create a new server/handler (new API/mux/rate limiter instance) per t.Run and assert only 200, 401, 400, 404, 408, 500, or 504 (no 429).internal/models/response.go (1)
80-90: Minor: Consider usingmap[string]anyfor consistency.The rest of this file uses
map[string]any(lines 22, 31, 41, 55), but this function usesmap[string]interface{}. While functionally equivalent since Go 1.18, usinganywould maintain consistency.♻️ Optional consistency fix
- entryData := map[string]interface{}{ + entryData := map[string]any{ "arrivalsAndDepartures": arrivalsAndDepartures, "limitExceeded": limitExceeded, "nearbyStopIds": nearbyStopIds, "situationIds": situationIds, "stopIds": stopIds, } - data := map[string]interface{}{ + data := map[string]any{ "entry": entryData, "references": references, }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@internal/models/response.go` around lines 80 - 90, The maps entryData and data are declared with map[string]interface{} but the rest of the file uses map[string]any; update the declarations for both entryData and data to use map[string]any (keeping the same keys/values) to maintain type-consistency with other maps in this file (look for symbols entryData and data in response.go and replace interface{} with any).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal/restapi/arrivals_and_departures_for_location.go`:
- Around line 686-694: Replace direct accesses to nullable fields
trip.TripHeadsign.String and trip.DirectionID.Int64 with explicit .Valid checks:
compute a headsign variable (e.g., headsign := "" ; if trip.TripHeadsign.Valid {
headsign = trip.TripHeadsign.String }) and a direction string (e.g., dir := "" ;
if trip.DirectionID.Valid { dir = strconv.FormatInt(trip.DirectionID.Int64, 10)
}) and pass those into utils.FormCombinedID/strconv.FormatInt call sites instead
of accessing .String/.Int64 directly; apply the same pattern for any other
sql.NullString/sql.NullInt64 usages across handlers in internal/restapi (look
for trip.TripHeadsign and trip.DirectionID to locate occurrences).
---
Nitpick comments:
In `@internal/models/response.go`:
- Around line 80-90: The maps entryData and data are declared with
map[string]interface{} but the rest of the file uses map[string]any; update the
declarations for both entryData and data to use map[string]any (keeping the same
keys/values) to maintain type-consistency with other maps in this file (look for
symbols entryData and data in response.go and replace interface{} with any).
In `@internal/restapi/context_cancellation_test.go`:
- Around line 84-95: The test currently allows HTTP 429 as an acceptable
response which can mask failures in context-cancellation handling because all
sub-tests share the same rate limiter; update the test to initialize a fresh
API/mux (and its rate limiter) for each sub-test so limiter state is isolated,
and remove http.StatusTooManyRequests from the accepted status list in the
assertion; specifically, change the sub-test setup to create a new
server/handler (new API/mux/rate limiter instance) per t.Run and assert only
200, 401, 400, 404, 408, 500, or 504 (no 429).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: bc9fb6dd-17be-430c-ba39-c3c40fb2fe67
📒 Files selected for processing (12)
gtfsdb/query.sqlgtfsdb/query.sql.gointernal/models/arrival_and_departure.gointernal/models/response.gointernal/models/stops.gointernal/restapi/arrivals_and_departures_for_location.gointernal/restapi/arrivals_and_departures_for_location_test.gointernal/restapi/arrivals_and_departures_for_stop_handler.gointernal/restapi/context_cancellation_test.gointernal/restapi/input_validation_integration_test.gointernal/restapi/routes.gointernal/restapi/trips_helper.go
….go for consistency
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@internal/models/response.go`:
- Around line 62-92: In NewArrivalsAndDeparturesForLocationResponse ensure the
arrivalsAndDepartures parameter is normalized to an empty slice when nil so it
serializes as [] instead of null; update the function near the existing nil
checks for nearbyStopIds/situationIds/stopIds to add a check for
arrivalsAndDepartures and set it to an empty []ArrivalAndDeparture when nil
before building entryData so the response schema stays stable.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 36c1862c-4a85-4e03-9758-55bb99397822
📒 Files selected for processing (1)
internal/models/response.go
|
Hi @aaronbrethorst , @Ahmedhossamdev I resolved merge conflicts and failing test The PR is ready for review.... |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
gtfsdb/query.sql (1)
677-677: 💤 Low valueConsider making sort direction explicit.
SQL defaults to ascending order, but explicitly specifying
ASCimproves readability and makes intent clearer.✨ Proposed change for clarity
-ORDER BY a.id, stop_times.stop_id; +ORDER BY a.id ASC, stop_times.stop_id ASC;🤖 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 `@gtfsdb/query.sql` at line 677, The ORDER BY clause at the end of the query ("ORDER BY a.id, stop_times.stop_id") relies on implicit ascending order; update it to be explicit by appending ASC to each sort key (e.g., ORDER BY a.id ASC, stop_times.stop_id ASC) to improve readability and make intent clear when editing or reviewing the query.
🤖 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 `@gtfsdb/query.sql`:
- Line 677: The ORDER BY clause at the end of the query ("ORDER BY a.id,
stop_times.stop_id") relies on implicit ascending order; update it to be
explicit by appending ASC to each sort key (e.g., ORDER BY a.id ASC,
stop_times.stop_id ASC) to improve readability and make intent clear when
editing or reviewing the query.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 3b49acfa-42da-4c3b-bcaf-5b07cf917b5a
📒 Files selected for processing (6)
gtfsdb/query.sqlgtfsdb/query.sql.gointernal/models/arrival_and_departure.gointernal/restapi/arrivals_and_departures_for_stop_handler.gointernal/restapi/routes.gointernal/restapi/trips_helper.go
🚧 Files skipped from review as they are similar to previous changes (5)
- internal/models/arrival_and_departure.go
- internal/restapi/routes.go
- internal/restapi/arrivals_and_departures_for_stop_handler.go
- internal/restapi/trips_helper.go
- gtfsdb/query.sql.go
There was a problem hiding this comment.
🧹 Nitpick comments (2)
internal/restapi/arrivals_and_departures_for_location.go (2)
586-589: ⚡ Quick winDon't swallow batch-fetch errors; propagate at least context cancellation.
When
batchFetchLocationRoutesAndTripsfails (e.g., ctx cancellation, DB outage), this returns(false, nil), so the outer per-stop loop inarrivalsAndDeparturesForLocationHandlercontinues iterating over the remaining stops despite the client having gone away or the DB being unhealthy. The internal warning log in the batch helper doesn't help the request loop short-circuit. The inner loop already callsclientCanceledResponseforctx.Err()at line 599–602; do the same here so cancellation/timeout failures actually abort the handler.♻️ Proposed change
routesLookup, tripsLookup, tripStopCountMap, bErr := api.batchFetchLocationRoutesAndTrips(ctx, stopCode, allActiveStopTimes) if bErr != nil { - return false, nil + if ctx.Err() != nil { + api.clientCanceledResponse(w, r, ctx.Err()) + return false, ctx.Err() + } + return false, nil }🤖 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/arrivals_and_departures_for_location.go` around lines 586 - 589, The batchFetchLocationRoutesAndTrips error is being swallowed (returning false, nil) which prevents request-level cancellation/DB errors from aborting arrivalsAndDeparturesForLocationHandler; change the handling after calling batchFetchLocationRoutesAndTrips so that if bErr != nil you check ctx.Err(): if ctx.Err() != nil call clientCanceledResponse(ctx) (as done in the inner loop) and return its result, otherwise propagate/return the bErr (or a wrapped error) so the handler short-circuits on DB failures instead of continuing to the next stop. Ensure you update the branch that currently returns (false, nil) to return the appropriate cancellation response or the error from batchFetchLocationRoutesAndTrips.
297-309: ⚡ Quick winSeveral DB/spatial errors are silently dropped.
A few call sites in this handler discard returned errors with
_:
- Line 297:
stops, _ := api.GtfsManager.GetStopsForLocation(...)— a failure in the bbox query yields the same "no stops" path as a legitimately empty result, including triggeringemptyReturnsNotFound404s. The caller can't distinguish "out of area" from "lookup failed".- Lines 898–899:
GetStopsByIDsandGetRoutesForStopserrors are dropped during references assembly, which can yield a silently truncatedreferencesblock (missing stops/routes) without any log line.At minimum, log these errors (e.g., via
api.Logger.Warn) so failures are observable; the line-297 error in particular is worth surfacing as a 5xx since it gates the entire response shape. This matches the warn-and-degrade pattern you already use elsewhere in this file (e.g.,fetchStopTimesForDayOffset).Also applies to: 898-899
🤖 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/arrivals_and_departures_for_location.go` around lines 297 - 309, The handler currently ignores errors from api.GtfsManager.GetStopsForLocation and later calls GetStopsByIDs/GetRoutesForStops, causing silent failures; update the call sites (GetStopsForLocation in the arrivals_and_departures_for_location handler and the GetStopsByIDs/GetRoutesForStops usages during references assembly) to capture the returned error, log it with api.Logger.Warn (including context like the location params or stop IDs), and for the initial GetStopsForLocation error return an appropriate 5xx response instead of treating it as an empty result (preserve the existing emptyReturnsNotFound flow only for legitimately empty slices); follow the existing warn-and-degrade pattern used by fetchStopTimesForDayOffset for non-fatal downstream errors so references are logged when truncated.
🤖 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/arrivals_and_departures_for_location.go`:
- Around line 586-589: The batchFetchLocationRoutesAndTrips error is being
swallowed (returning false, nil) which prevents request-level cancellation/DB
errors from aborting arrivalsAndDeparturesForLocationHandler; change the
handling after calling batchFetchLocationRoutesAndTrips so that if bErr != nil
you check ctx.Err(): if ctx.Err() != nil call clientCanceledResponse(ctx) (as
done in the inner loop) and return its result, otherwise propagate/return the
bErr (or a wrapped error) so the handler short-circuits on DB failures instead
of continuing to the next stop. Ensure you update the branch that currently
returns (false, nil) to return the appropriate cancellation response or the
error from batchFetchLocationRoutesAndTrips.
- Around line 297-309: The handler currently ignores errors from
api.GtfsManager.GetStopsForLocation and later calls
GetStopsByIDs/GetRoutesForStops, causing silent failures; update the call sites
(GetStopsForLocation in the arrivals_and_departures_for_location handler and the
GetStopsByIDs/GetRoutesForStops usages during references assembly) to capture
the returned error, log it with api.Logger.Warn (including context like the
location params or stop IDs), and for the initial GetStopsForLocation error
return an appropriate 5xx response instead of treating it as an empty result
(preserve the existing emptyReturnsNotFound flow only for legitimately empty
slices); follow the existing warn-and-degrade pattern used by
fetchStopTimesForDayOffset for non-fatal downstream errors so references are
logged when truncated.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 0456dcd8-41d9-4b3b-8e18-40b34e00e525
📒 Files selected for processing (3)
gtfsdb/helpers.gogtfsdb/query.sqlinternal/restapi/arrivals_and_departures_for_location.go
🚧 Files skipped from review as they are similar to previous changes (1)
- gtfsdb/query.sql
…rOfStopsAway fallback for OBA Java parity
ARCoder181105
force-pushed
the
feature/arrivals-departures-for-location
branch
from
0301916 to
ccf440f
Compare
|
Hi @aaronbrethorst , @Ahmedhossamdev , This PR is ready for review! I was able to successfully replicate the behavior of the legacy Java OBA output for this endpoint. I verified the data parity using this PROD link: Please take a look whenever you have time. |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
internal/restapi/context_cancellation_test.go (1)
84-94: ⚡ Quick winAvoid masking cancellation behavior with rate-limit outcomes.
Allowing 429 here makes the test pass even when cancellation logic regresses. Prefer isolating this test from rate limiting (e.g., dedicated high-limit test API / key) and keep expected statuses focused on cancellation and handler outcomes.
🤖 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/context_cancellation_test.go` around lines 84 - 94, The test currently allows http.StatusTooManyRequests which masks cancellation regressions; in the assertion in context_cancellation_test.go (the block checking statusCode) remove StatusTooManyRequests from the allowed statuses and instead ensure the test uses an isolated high-rate test key or test server (e.g., configure the request setup that exercises the cancellation path in the same test harness) so that rate limiting cannot produce 429s—update the assertion to only accept 200, 401, 400, 404, 500, 408, or 504 and adjust the test setup (API key/limit or dedicated endpoint) to prevent 429 responses during this test.internal/restapi/arrivals_and_departures_for_location_handler_test.go (1)
476-493: ⚡ Quick winAssert
entry.limitExceededexplicitly in the limit test.The test currently only checks returned item count. Please also assert
entry["limitExceeded"] == truewhen truncation happens so the API contract is fully covered.🤖 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/arrivals_and_departures_for_location_handler_test.go` around lines 476 - 493, The test TestArrivalsAndDeparturesForLocationLimitExceeded only asserts the number of arrivals but not the API contract flag; update the test after extracting entry (in TestArrivalsAndDeparturesForLocationLimitExceeded) to explicitly assert that entry["limitExceeded"] is present and true (e.g., require.True/assert.Equal on entry["limitExceeded"] == true) so the case where results are truncated is validated alongside the length check.
🤖 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.
Inline comments:
In `@internal/restapi/arrivals_and_departures_for_location_handler.go`:
- Around line 483-494: The code computes maxBefore/maxAfter but still uses
params.MinutesBefore and params.MinutesAfter when building the time window;
update the stopWindowStart and stopWindowEnd calculations inside the handler so
they use maxBefore and maxAfter instead of
params.MinutesBefore/params.MinutesAfter. Locate the block where stopWindowStart
and stopWindowEnd are set (references: maxBefore, maxAfter, stopWindowStart,
stopWindowEnd, spc.QueryTime) and replace the direct params values with the
computed maxima that include params.FrequencyMinutesBefore and
params.FrequencyMinutesAfter.
---
Nitpick comments:
In `@internal/restapi/arrivals_and_departures_for_location_handler_test.go`:
- Around line 476-493: The test
TestArrivalsAndDeparturesForLocationLimitExceeded only asserts the number of
arrivals but not the API contract flag; update the test after extracting entry
(in TestArrivalsAndDeparturesForLocationLimitExceeded) to explicitly assert that
entry["limitExceeded"] is present and true (e.g., require.True/assert.Equal on
entry["limitExceeded"] == true) so the case where results are truncated is
validated alongside the length check.
In `@internal/restapi/context_cancellation_test.go`:
- Around line 84-94: The test currently allows http.StatusTooManyRequests which
masks cancellation regressions; in the assertion in context_cancellation_test.go
(the block checking statusCode) remove StatusTooManyRequests from the allowed
statuses and instead ensure the test uses an isolated high-rate test key or test
server (e.g., configure the request setup that exercises the cancellation path
in the same test harness) so that rate limiting cannot produce 429s—update the
assertion to only accept 200, 401, 400, 404, 500, 408, or 504 and adjust the
test setup (API key/limit or dedicated endpoint) to prevent 429 responses during
this test.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 1d368b31-47f2-4495-97ca-cf22a78b85ce
📒 Files selected for processing (18)
gtfsdb/helpers.gogtfsdb/query.sqlgtfsdb/query.sql.gointernal/models/arrival_and_departure.gointernal/models/response.gointernal/models/situation.gointernal/models/stops.gointernal/restapi/arrival_and_departure_for_stop_handler.gointernal/restapi/arrivals_and_departures_for_location_handler.gointernal/restapi/arrivals_and_departures_for_location_handler_test.gointernal/restapi/arrivals_and_departures_for_stop_handler.gointernal/restapi/context_cancellation_test.gointernal/restapi/coverage_test.gointernal/restapi/input_validation_integration_test.gointernal/restapi/reference_utils.gointernal/restapi/routes.gointernal/restapi/trips_helper.gointernal/restapi/trips_helper_test.go
💤 Files with no reviewable changes (1)
- internal/restapi/trips_helper_test.go
|
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
Reference: Arrivals and Departures for Location Endpoint1. OverviewThis document serves as a technical reference for the Purpose: To retrieve all active scheduled and real-time arrivals/departures for transit stops within a specified geographic bounding box ( 2. Architectural Flow & Performance
To maintain high performance across a wide geographic radius, the data fetching is heavily batched to avoid N+1 query bottlenecks.
3. Key Heuristics & Edge Cases3.1 Stop Sequence Inference (Nearest-Stop Fallback)Not all transit agencies provide 3.2 Arrival Status DerivationArrival statuses (
4. Known Parity DeviationsThe core math (deviations, distances, sequences) is strictly verified against Java OBA. However, there are a few intentional formatting and serialization differences to align with Go's standard library and OpenAPI conformance:
5. Testing & VerificationParity was verified using the following production payload: All |
3 participants
Overview
This PR ports the
arrivals-and-departures-for-locationendpoint from the legacy Java codebase into the Gomaglevarchitecture. This endpoint allows clients to retrieve active arrivals and departures for multiple stops within a specified geographic bounding box or radius.Key Features
referencesblock to strictly adhere to the legacy JSON schema and optimize payload size.nearbyStopIdsto identify and include stops within the radius that may not currently have active arrivals.Bug Fixes
arrivals_and_departure_for_stop.gowhere thevehicleparameter was incorrectly passed asniltoBuildTripStatus.Testing
fix #799
Summary by CodeRabbit
New Features
Bug Fixes
Tests