Rapido: the SLA breaches with no row to join to

Constraints

1. 1requests counts every row in rapido_requests for that city — 5 for Bengaluru, 3 for Hyderabad, 4 for Pune.
2. 2A request meets the SLA when its first driver_assigned event is 60 seconds or less after requested_at.
3. 3A request with no driver_assigned event is a breach, not a missing row. Requests 303, 307 and 311 are exactly that.
4. 4Retries do not count separately. Request 301 has two assignment events; only the earliest decides the outcome.
5. 5within_sla plus breached must equal requests for every city.
6. 6Order by breach_rate_pct descending, then city.

Worked example

Hyderabad has 3 requests. 305 was assigned in 30 seconds, 306 took 140 seconds, and 307 never found a driver — no row in the events table. The honest answer is 1 within SLA, 2 breached, a 66.7% breach rate. Join the two tables and count what you find, and 307 disappears: Hyderabad reports 2 requests with a 50% breach rate. The worst outcome in the dataset — a rider who was never served — is the one the join cannot see, so the metric flatters exactly where it should not.

What this tests

That the rows which are absent carry the signal. Any SLA, funnel or coverage metric has to be driven from the table that contains every attempt, with the outcome joined onto it, or the failures quietly leave the denominator.