Cancelled bookings kept showing on the drivers' phones

A customer cancels. Your office cancels the booking on the booking site, as it always has, and moves on. Next week the booking is still on the operations board in the back-office portal, still on the driver’s phone, and the portal is about to email the customer asking for their documents for a trip they are not taking. Or the office swaps the car on a live booking, and the driver turns up with the one that was swapped out.

The owner of a self-drive car rental business in Goa reported the first of these with five booking codes. Measured against the live system, it was larger than five. 64 bookings that no longer existed on the booking site were still in the portal. 19 live driver assignments sat on cancelled reservations. And 103 of the 5,193 live assignments pointed at a car the booking no longer used, every one of them changed after the driver had been given the job.

What was actually going on

The portal takes its bookings by copying from the public booking site. A copy can only see what is there. When the office deleted a booking outright on the booking site, there was nothing left to copy, so the portal’s version stayed exactly as it was, indefinitely.

Cancellation was a different fault. The copy did know how to carry a cancellation across for a booking it had seen before. But a booking that was already cancelled the first time the portal saw it was created as a new, open booking waiting for documents, and never looked at again. Those were the ones about to be emailed.

Even when a booking did get cancelled in the portal, the driver’s job was a separate record, and cancelling the booking never touched it. So the phone kept showing the job.

The car was the same shape of problem. When the office assigned a driver, the job recorded which car at that moment, and kept it. Every later change of car on the booking was invisible to the driver, because his phone was reading the job, not the booking.

We nearly reported that last figure as 5,193 rather than 103, which would have been every live assignment. The first comparison joined the job’s car to the wrong column in the vehicle table. Checking the join before reporting the number is the difference between a finding and a false alarm.

What we changed

A job now runs daily and removes from the portal any booking that has been deleted on the booking site, recording each removal in the booking’s history, with guards against removing too many at once. The 64 stale bookings were cleared the same way.

The copy now checks the status on both of its paths, including the one that creates a booking for the first time, and a repair step in the half-hourly job catches any booking whose cancellation drifted. On the test system the first sweep cancelled 15 stuck bookings, including the three the owner had reported.

The driver’s list now excludes cancelled bookings by both status fields the system carries, and does so in a way that tolerates a booking where one of them is blank, because a plainer check would have dropped the one live job whose second status was empty. And the driver’s app now reads the car through to the booking’s current one, rather than the one frozen on the job, which also fixes the deposit the driver is told to collect and the odometer and fuel readings pre-filled on his handover screen. Proved by running the real code against production data, read-only, and watching the 103 drifted jobs flip to the right registration.

What it did not fix

The portal still cannot see a deletion the moment it happens. It finds out at the next daily sweep, so a booking deleted in the morning is on the board until the following night.

The copy only knows about cancellations the booking site records as cancellations. A booking abandoned some other way, on the phone, in a spreadsheet, is still a booking to the portal.

The mechanism, briefly

Hard deletes upstream never reach a sync that only reads existing rows, so a daily purge diffs the portal against the source. Status reconciliation was added to both sync paths and a cancelled-drift repair to the 30-minute job. The driver query filters on status and rentalStatus, null-safe, because a bare != 'Cancelled' drops the row whose value is NULL. The assignment’s vehicleId was denormalised at assign time; the driver payload now resolves through the reservation’s current vehicle, and the vehicle join goes through rentalVid, not id, which is where the 5,193 false alarm came from.

Where this ends up

A driver sent to a cancelled booking is a copy that stopped at the record and never reached the person doing the job, which is why Sazinga Rentals reads the driver’s job through to the booking as it stands now, not as it stood when the job was handed out.