Recover a route search when the timetable changes mid-session
A timetable refresh replaces station and trip data while a route calculation still reads the old version. The result combines a new platform with a removed connection.
- Focused work estimate
- 3h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Snapshot consistency · Transactions · Offline data
Estimated field mix
- Mobile60%
- Database engineering40%
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.
- TRIP-101 · Give saved journeys names that survive station renames
- TRIP-102 · Keep the last train on the correct service day
- TRIP-104 · Label stale departures when the live feed stops responding
- TRIP-105 · Apply cancellation updates to the right departure instance
- TRIP-106 · Stop refreshing a journey after the rider leaves it
Acceptance criteria
- A search reads one timetable snapshot/version for its entire calculation.
- A result from an obsolete snapshot is explicitly revalidated or replaced before being labeled current.
- Interrupted dataset replacement leaves either the old complete dataset or the new complete dataset available.
Implementation constraints
- Use synthetic small datasets and a local transaction; implementing a nationwide routing engine is excluded.
Verification to include
- Swap timetable versions during calculation and verify every returned leg belongs to one version.
- Fail replacement halfway through and restart; searches use a complete version and unavailable connections are not invented.
Deliverables
- Versioned timetable handoff and interrupted-update tests
Rollout and recovery
Stage updates beside the active dataset; switch the active pointer back if validation fails and retain prior-version diagnostics.
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.