Apply cancellation updates to the right departure instance
Canceling the 08:10 Line 4 also marks tomorrow’s 08:10 as canceled because the cache key contains only the route. Reconcile alerts by departure identity.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Event ordering · Cache identity · Data reconciliation
Estimated field mix
- Mobile50%
- Real-time systems30%
- Data engineering20%
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
- Cancellation identity includes service date and trip instance rather than route label alone.
- A newer correction can restore a departure while an older cancellation cannot overwrite it.
- Unknown alert references remain diagnosable without canceling unrelated trips.
Implementation constraints
- Define ordering from feed revision metadata, not arrival order on the device.
Verification to include
- Cancel today’s instance and verify tomorrow’s matching route stays available.
- Deliver correction and cancellation out of order; the newest revision wins and unknown IDs change no journey.
Deliverables
- Departure alert reducer and ordering regression tests
Rollout and recovery
Shadow-reconcile synthetic alerts before display; fall back to a general service notice if precise mapping is unavailable.
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.