Removing a driver from a booking did nothing on one screen

The report was simple. In a car rental business’s booking system, pressing the control that removes a driver from a booking did nothing. The screen said the request had gone through and still showed the driver. Do the same thing from the assignment board and it worked.

An action that appears to succeed and changes nothing is the worst kind of fault to live with. The staff member presses it twice, tries the other screen, and stops trusting the system. And the record of who was on which job, the thing you would use to settle a dispute about a pick-up, is quietly wrong.

The owner’s own theory was that the two screens were saving different things: one storing the driver’s id, the other something else. It was worth checking, and it was wrong.

What was actually going on

Rather than reason about the two screens, we checked every live assignment record in production at once: 5,425 of them. There were no broken driver references, no drivers without a ten-digit phone number, and no mismatches between the two identifiers a booking carries. Both screens feed the same dropdown. What is saved is identical whichever screen saves it.

The difference was not what got saved. It was which record.

The assignment board updates the newest live record for a leg, which is the one the portal shows. The booking screen used a different, careless lookup: it asked the database for one record matching three details, with no rule about deleted records and no rule about which to pick. When several matched, it returned an arbitrary one. So the removal landed on a deleted record that no screen displays, saved faithfully there, and reported success.

The booking’s own log showed it: a driver assigned to the drop-off leg at 09:57:06, then an update to that leg eighteen seconds later naming no driver at all. Two records, one live and holding the driver, one deleted and now holding the removal.

Fixing it properly meant finding a second problem. The details used to match were not unique. For any booking that did not come from the outside platform, such as counter bookings made in our own system, the system saves a fixed placeholder for the platform’s booking reference. In the test copy, six live pick-up records across six different customers’ bookings all carried the identical one. So the old lookup could update a completely different customer’s booking. Sorting the results by newest would only have made it predictable which stranger you overwrote.

What we changed

The lookup now uses the booking’s own id wherever the screen supplies it, which is what the create path already did, and the four places in the portal that had been leaving that id out were corrected. On the six colliding bookings, the old match found six records each and the new one finds exactly one, that booking’s own. Swept across all 5,425 live records in production and 5,337 in the test copy, every record resolves to exactly one, none ambiguous and none newly missing.

That last sweep is what told us the fix was complete. The reported case was one booking. Re-running the measurement that found the bug, on the whole population, is what also showed we had not broken records that were working.

Two more things fell out. The helper that expands a leg name into its spellings listed three ways of writing “pick-up” and not the spelling its own caller used, so a record saved that way would have been invisible to every lookup. And every removal had been recorded in the log as “driver removed - null”: 36 historic entries, none saying who was taken off. The log read the driver from the record after the update had already changed it. It now captures the before-state first.

What it did not fix

That log mistake mattered more than it looks. When a later clean-up left seventeen legs with only deleted records, so every screen reported no driver on pick-ups that had definitely happened, the log was the only place the answer could have come from, and it could not give it.

The records were reinstated from the deleted ones themselves, guarded so the migration could neither bring back a duplicate nor run twice. Seven records whose driver id had been wiped in place could not be recovered.

The pattern, for anyone with a booking or job system

Press every button that changes something, from every screen where it appears, and look at the record afterwards rather than at the confirmation. A screen that says it worked is not evidence that the right record changed.

Then ask what your audit trail captures. A log written from the record after the change describes the change after it has already happened, and on the day you need it, the record it describes may no longer exist.

Where this ends up

Which driver is on which leg, and when that changed, is the record Sazinga Rentals keeps behind a booking. A lookup that returns an arbitrary record is the difference between that history being an account of the work and being a guess about it.