A teammate’s pull request moves the pass lookup to the pass service, which can be down, and starts the phone’s haptics engine, which fails on some phones. To stop crash reports at startup, startRideFlow now replaces any collaborator that fails with its no-op. Product’s rules: haptics are optional, so a phone that cannot buzz should ride silently; the fare must never be computed from terms the rider doesn’t have.
When the pass service is down, every day-pass holder is charged pay-as-you-go fares, and riders whose pass this version doesn’t know are charged the same, with nothing reported anywhere. Support learns about it from refund requests.
Reproduce
The pass service is down and ana holds a day pass. startRideFlow(dock, { hapticsOn: true, engineStarts: false }, new PassService(false), "ana") should refuse with “pass service unavailable”; today the ride starts and is priced as pay as you go.
Acceptance criteria
- A phone whose haptics engine won’t start still rides: unlocks and dockings report their results and nothing is felt.
- A pass lookup that fails stops the ride from starting with the service’s reason; it is never priced as no pass.
- A pass kind this version doesn’t know still stops the ride with “unknown pass: <kind>”.
- Everything earlier still holds: fares by pass, nothing felt with haptics off, failures never pulse, and the account screen shows the rider’s pass.
Notes
- Riders: ana holds a day pass, ben none, and cy a gold pass this version doesn’t know.
- Ride cases print the unlock and the receipt, or “rejected (<reason>)” when startRideFlow fails, then what was felt.
- Keep the names and signatures the checker calls. The checker makes a fresh dock, phone and pass service for every case.