Tagging one handover photo quietly deleted another
Office staff label each handover photo. Relabelling one removed the photo that held the label, and the next click failed six times in a row.
Your office labels every handover photo with what it shows: front of the car, odometer, fuel gauge. One morning an operator tags a photo, clicks the next one, and gets an error. She clicks again. Six times in a row the same click failed.
The error was the small problem. Behind it, a photo the driver had actually taken, which is the evidence if a customer disputes damage later, had been destroyed because its label was given to a different photo. For GOI Car & Taxi, a self-drive and taxi hire business in Goa, handover photos are the record of the car’s condition. Losing one because of a tidy-up rule is the kind of thing nobody sees until a dispute.
What was actually going on
We found it while reading the live server’s error log, which had no timestamps and no rotation, 761 KB going back weeks. We dated each error by where it sat between restart markers. Only one kind was still live: “Photo not found”, 16 in total, 7 since the restart on 20 July and 6 on the day we looked.
We also got something wrong first. A batch of 37 database errors looked serious, and we flagged them. They all predated 20 July and the column in question was already fixed on both systems. Those were history, and we withdrew them.
The live one came from a rule: each label may belong to only one photo on a booking. The server enforced it by deleting the photo that currently held the label. The office screen’s equivalent only cleared the label and kept the photo. The screen then sorted untagged photos to the top of the worklist, and the deleted one, now unlabelled in the screen’s eyes, sat there. The operator’s next click used an id that no longer existed.
The scale, as best we could tell: on one assignment, three label types each had a deleted photo and no live photo holding them. Across 304 deleted photo rows, 13 still carried a label.
What we changed
The rule now clears the old photo’s label instead of deleting it, so the photo survives and returns to the untagged worklist. A genuinely missing photo returns a plain “not found” message instead of a crash trace. The office screen reloads its list on a not-found reply rather than leaving a dead row to be clicked again.
What it did not fix
Photos already deleted this way are not recovered by the change, and the log does not record any being restored. The figure of 13 is an upper bound: deliberate deletions also keep their label, so we cannot separate relabelling victims from ordinary deletes.
The pattern, for anyone with photos as evidence
Whenever a rule says only one record may have a given label, ask what the system does to the record that held it before. Re-labelling should move a label, not remove evidence.
A cheap check: take a booking, relabel a photo, and count the photos before and after. The number should not change.
Where this ends up
Treating a handover photo as evidence that is never discarded for housekeeping is part of how Sazinga Rentals handles condition records.