Label stale departures when the live feed stops responding
The departures screen keeps displaying an old prediction after a feed outage. A rider mistakes a 12-minute-old estimate for a live arrival.
- Focused work estimate
- 1h 45m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Freshness modeling · Error recovery · Time handling
Estimated field mix
- Mobile60%
- Real-time systems40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
The fictional Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection.
Setup prerequisites
- Synthetic timetable with explicit time zones and service dates
- Departure, alert, and permission adapters with failure fixtures
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Predictions show source update time and become stale at the configured fixture threshold.
- Scheduled times remain available but are visibly distinguished from current predictions.
- A failed refresh preserves readable departures and provides a retry action.
Implementation constraints
- Calculate staleness from trusted feed timestamps with a documented clock-skew allowance.
Verification to include
- Advance a fake clock across the freshness threshold and inspect the label change.
- Return a future-dated update beyond allowed skew and then fail refresh; do not display it as trustworthy live data.
Deliverables
- Departure freshness policy and fake-clock tests
Rollout and recovery
Enable stale labels for one synthetic feed; disable live prediction display if timestamps cannot be validated.
Value of the work
For the engineer: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design.
For the team: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.