Show a banner when OBA realtime predictions are unavailable #2301

When an agency's realtime data disappears from the OBA backend, the app silently falls back to scheduled arrivals. Every arrival looks scheduled, with no explanation of the broader problem. Riders cannot tell whether realtime is unavailable, the trips simply have no predictions yet, or the app has regressed.

Proposed behavior

Show a compact, nonblocking banner on the affected arrivals view when a realtime outage is established. For example:

Realtime predictions for King County Metro are currently unavailable. Showing scheduled times.

• Scope the message to the affected agency/service. A failure in one agency must not imply that the entire OBA region is down.
• Keep scheduled arrivals usable and clearly identified as scheduled.
• Clear the banner when realtime service recovers, and update it appropriately when the rider changes stops or regions.
• Distinguish missing backend realtime data from the phone being offline or an arrivals request failing.

Observed example: Puget Sound, September 7, 2026

Direct HTTPS requests to api.pugetsound.onebusaway.org, using API version 2 and the Android app's API key, reproduced the missing data independently of Android decoding or rendering.

At 3:59 PM Pacific, arrivals-and-departures-for-stop with minutesBefore=5&minutesAfter=60 returned:

All 62 arrivals across 16 Metro routes had predicted: false, predictedArrivalTime: 0, and predictedDepartureTime: 0.

At 4:08 PM Pacific, trips-for-route with includeStatus=true&includeSchedule=false returned:

• Metro route 12 (1_100018): 10 trip statuses, none realtime.
• Metro route 40 (1_102574): 24 trip statuses, none realtime.
• Both Metro responses had zero update timestamps and empty vehicle IDs.
• Sound Transit route 594 (40_594), on the same backend: 11 realtime trip statuses, with updates roughly 20–25 seconds old.

This establishes an agency-specific absence of realtime data in the backend responses. It does not establish whether the underlying cause was Metro's source feed, OBA ingestion, or realtime-to-schedule matching.

Detection needs design

A stop returning only scheduled arrivals is not, by itself, proof of an outage: this can be normal for future trips, services without realtime support, or periods without active service. Prefer an explicit backend/agency health signal if available. Define the detection and recovery contract before implementing client-side inference; do not label ordinary scheduled-only service as an outage.

Acceptance criteria

• An established realtime outage produces an explanatory banner for affected arrivals.
• An agency-specific outage leaves unaffected agencies' realtime presentation intact.
• Ordinary scheduled-only arrivals, empty arrival lists, and device/network failures do not incorrectly trigger the outage banner.
• Recovery and stop/region changes remove or update the banner without requiring an app restart.
• Tests cover outage, partial agency outage, recovery, and the normal scheduled-only cases.