Repository navigation
Name a route's stops by their own agency - #1795
aaronbrethorst wants to merge 2 commits into
Conversation
loadStopAgencyIDs now takes whole routes and every trip near a location, which can exceed SQLite's bind limit. Run it through QueryInBatches like the other stop lookups.
stops-for-route and schedule-for-route prefixed every stop with the route's agency: entry stopIds, stop groups, the stops list and the schedule's stop times. A route of an agency other than the feed's first showed its stops under IDs Java OneBusAway doesn't have. Both now read each stop's agency through loadStopAgencyIDs: stops-for-route once per request, alongside the stop coordinates in routeStopSequences, and schedule-for-route once per direction group. processTripGroups and buildStopGroup used the route's agency only for stop IDs, so they no longer take it.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
 |
|
@aaronbrethorst, the PR description does not follow the PR template:
Keep this PR as Draft until these are fixed. This comment updates when the description changes. |
|
Performance Smoke Test ResultsStatus: PASSED
Smoke test config: 5 VUs x 30s. Thresholds: p(95) < 300ms, error rate < 1%. Full results uploaded as workflow artifact: k6-smoke-summary. |
|
Closing as superseded. The multi-feed static GTFS spec (#1811, |
Stacked on #1794. Part of the stop consolidation work (#1771–#1779). No issue filed yet.
What it does
These now carry each stop's own agency, not the route's:
stops-for-route:stopIds, stop groupstopIds, and the stop records inreferences.stopsschedule-for-route:stopTripGroupings[].stopIdsandtripsWithStopTimes[].stopTimes[].stopIdIt also batches
loadStopAgencyIDsthroughutils.QueryInBatches, because whole routes and the trips-for-location bulk loader can pass more IDs than SQLite allows in one statement.Root cause
Both handlers prefixed every stop with the route's agency. Java OneBusAway names a stop after its feed's first agency, so a route of any other agency listed stops under IDs that don't exist.
Both now read each stop's agency through
loadStopAgencyIDs:stops-for-routereads it once per request, alongside the stop coordinates inrouteStopSequences.schedule-for-routereads it once per direction group.processTripGroupsandbuildStopGroupused the route's agency only for stop IDs, so they no longer take it.Testing
mainbefore this change:TestRouteStopIDs_UseTheStopsOwnAgency, on the two-agency fixture.stops-for-route/other_other-routeandschedule-for-route/other_other-route.other_stop-Nbefore this change and isown_stop-Nnow.Response comparison
StopEntriesFactory). Productionstop/29_16140returnsnulleven though Community Transit route29_130serves1_16140.stops-for-route/29_130would list29_16140.1_16140.Checklist
mainand passes on this branch.gtfsdb/(db.go,models.go,query.sql.go) ortestdata/openapi.yml(synced from upstream).r.Context()to DB/service calls, notcontext.Background().testdata/openapi.yml, has an issue open on OneBusAway/sdk-config, or is outside the SDK and the description says why.Notes for reviewers
loadStopAgencyIDsin Find stops only under the agency in their ID #1792. Putting it there would mean force-pushing Build stop records under each stop's own agency #1793 and Name a trip's stops by their own agency #1794, so it's the first commit here instead. Name a trip's stops by their own agency #1794 is the first PR that passes large lists.buildStopsListinstops-for-routestill builds stop records by hand instead of usingstopModelsByIDs, and so does the block handler. Merging both into the shared builder is a follow-up.