GTFS-RT Trip Updates > fix static data used too small.

[mmathieum]

Max 3 days is not enough to make sure we always have 2 next departures (incl. far away static)

(bug of Friday PM with routes service ending on Friday before Week-End breaks)

Summary by CodeRabbit

• Bug Fixes
  • Improved matching and processing of real-time trip updates against scheduled transit data for more consistent results.
  • Refined schedule caching and timestamp handling, including when to avoid redundant “no data” refreshes.
  • Updated GTFS schedule status request/caching parameters to align with the default fetch behaviour.
• Documentation
  • Added clarification on how schedule timestamps are sourced.

[coderabbitai]

Warning

Review limit reached

@mmathieum, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 26 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

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, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: fa31dc45-a915-4e89-bfcd-db084268b326

📥 Commits

Reviewing files that changed from the base of the PR and between 1a17196 and 1e7ab96.

📒 Files selected for processing (1)

• src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt

📝 Walkthrough

Walkthrough

GTFS status defaults now reference a shared request limit. Real-time trip updates use UUID-based schedule selection, while schedule caching retains timestamp filtering and metadata updates with renamed parameters and clearer conditions.

Changes

GTFS status and real-time schedule updates

Layer / File(s)	Summary
GTFS status defaults src/main/java/org/mtransit/android/commons/provider/gtfs/GtfsStatusProviderExt.kt, src/main/java/org/mtransit/android/commons/data/Schedule.java	The maximum request default now uses ScheduleStatusFilter.MAX_DATA_REQUESTS_DEFAULT; comments document shared-cache fetch timing and the route-to-timestamp mapping.
Real-time schedule processing src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProvider.kt, src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt	Caching uses the renamed rdSchedules parameter and equivalent timestamp filtering, while trip updates select relevant schedules through a UUID-indexed map.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title points to the GTFS-RT trip updates static-data fix and matches the PR’s main change, even if the wording is awkward.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch mm/gtfs_rt_tu_static_data_max_3_days_bug

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt (1)

55-68: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Restore a per-trip index before iterating updates.

Each trip update repeatedly scans all static timestamps to find matching schedules. With the expanded static window, this becomes tripUpdates × schedules × timestamps; precompute trip ID → RDS UUIDs once and reuse it.

Proposed refactor

 val rdSchedulesByUUID = rdSchedules.associateBy { it.targetUUID }
+val rdsUUIDsByTripId = mutableMapOf<String, MutableSet<String>>()
+rdSchedulesByUUID.forEach { (uuid, schedule) ->
+    schedule.timestamps.mapNotNull { it.tripId }.forEach { tripId ->
+        rdsUUIDsByTripId.getOrPut(tripId) { mutableSetOf() }.add(uuid)
+    }
+}
 rdTripUpdates.forEach { (td, gTripUpdate) ->
     val gTripId = td.optTripIdNotEmpty ?: return@forEach
     val tripId = parseTripId(gTripId)
-    if (rdSchedulesByUUID.none { (_, schedule) -> schedule.timestamps.any { it.tripId == tripId } })
-        return@forEach // trip ID not in static data
-    val tripRdsUUIDs = rdSchedulesByUUID
-        .filter { (_, schedule) -> schedule.timestamps.any { it.tripId == tripId } }
-        .keys
+    val tripRdsUUIDs = rdsUUIDsByTripId[tripId] ?: return@forEach
+    val tripSchedules = tripRdsUUIDs.mapNotNull { rdSchedulesByUUID[it] }
     // ...
-    val sortedTargetUuidAndSequence = makeTargetUuidAndSequenceList(tripId, rdSchedulesByUUID.values, tripSortedRDS)
+    val sortedTargetUuidAndSequence = makeTargetUuidAndSequenceList(tripId, tripSchedules, tripSortedRDS)

🤖 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
`@src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt`
around lines 55 - 68, In the flow around rdSchedulesByUUID and the
rdTripUpdates.forEach loop, precompute a tripId-to-RDS-UUID index from each
schedule’s timestamps before iterating updates. Replace the repeated
rdSchedulesByUUID scans used to validate the trip and build tripRdsUUIDs with
lookups into this index, preserving the existing skip behavior when no matching
static schedule exists.

🤖 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
`@src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt`:
- Around line 55-68: In the flow around rdSchedulesByUUID and the
rdTripUpdates.forEach loop, precompute a tripId-to-RDS-UUID index from each
schedule’s timestamps before iterating updates. Replace the repeated
rdSchedulesByUUID scans used to validate the trip and build tripRdsUUIDs with
lookups into this index, preserving the existing skip behavior when no matching
static schedule exists.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: db2c9dae-ae8e-43ee-8750-1484814e8560

📥 Commits

Reviewing files that changed from the base of the PR and between 2fcd635 and c001b9e.

📒 Files selected for processing (4)

• src/main/java/org/mtransit/android/commons/data/Schedule.java
• src/main/java/org/mtransit/android/commons/provider/gtfs/GtfsStatusProviderExt.kt
• src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProvider.kt
• src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt

[Copilot]

Pull request overview

This PR increases the amount of static schedule data fetched/used when processing GTFS-RT Trip Updates so that real-time matching can still yield at least a couple upcoming departures even when the next scheduled service is farther in the future (e.g., weekend gaps). It also refactors parts of the trip-update processing/caching pipeline for clarity.

Changes:

• Refactored trip-update processing to pre-index schedules by UUID and map trip IDs to the set of relevant stop UUIDs.
• Updated schedule caching helper signature/variable naming and clarified timestamp partition handling.
• Aligned the GTFS static schedule fetch defaults with ScheduleStatusFilter.MAX_DATA_REQUESTS_DEFAULT to avoid too-small static windows.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt	Refactors trip-to-static-schedule matching/indexing used during trip update processing.
src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProvider.kt	Renames/cleans up real-time schedule caching parameters and timestamp window logic.
src/main/java/org/mtransit/android/commons/provider/gtfs/GtfsStatusProviderExt.kt	Increases default static schedule request window by using ScheduleStatusFilter.MAX_DATA_REQUESTS_DEFAULT.
src/main/java/org/mtransit/android/commons/data/Schedule.java	Adds a brief clarifying comment about the Schedule’s conceptual mapping.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/main/java/org/mtransit/android/commons/provider/status/GTFSRealTimeTripUpdatesProviderExt.kt:136

• processRDTripUpdate now calls setTripDeleted / setTripCancelled on rdSchedulesByUUID.values (all schedules), even though only the schedules for the current trip can possibly be affected. This adds unnecessary iteration and makes the parameter name easy to misread as “trip-only”. You can derive the trip schedules from sortedTargetUuidAndSequence (already computed for this trip) and only update those.

    val gTripUpdateReadFromSourceMs = gTripUpdate.optTimestampMs ?: feedReadFromSourceMs
    if (gTripUpdate.optTrip?.optScheduleRelationship == GTDScheduleRelationship.DELETED) {
        rdSchedulesByUUID.values.setTripDeleted(tripId, gTripUpdateReadFromSourceMs)
        return
    }
    if (gTripUpdate.optTrip?.optScheduleRelationship == GTDScheduleRelationship.CANCELED) {
        rdSchedulesByUUID.values.setTripCancelled(tripId, includeCancelledTimestamps, gTripUpdateReadFromSourceMs)
        return