Audit log empty? Why nobody could say who changed what

If your audit log is empty when you need to know who changed a record, the usual cause is that the logging failed quietly: either it recorded a before and an after that were identical, or it called something that did not exist and the error went to a console nobody reads. The first check is to make one change, such as a rating or a phone number, and look for the line.

Here is how that looked at one hire business, and what fixing it took.

Someone changes the expiry date on a car’s insurance record. Or a customer’s bank details, which decide where a refund goes. You open the audit trail to see who, and there is nothing there. Not an old entry missing: no entry at all.

That was the state of the audit trail for a self-drive and taxi hire business in Goa, when we looked. Saves to a customer’s ID details, bank details, rating, damage record and odometer left no log line. The vehicle-document audit table had recorded zero changes against 1,231 vehicle documents. The cost is a risk rather than a figure: for any of those changes the question “who did this, and what was it before?” had no answer.

What was actually going on

Two unrelated faults with the same shape: the logging failed, and nothing said so.

The booking logger is meant to record the difference between a record before and after a save. It took its “before” copy after the save had already happened to the same object, so before and after were identical and the difference was always empty. Every save of ID, bank, rating, damage and fuel looked like no change.

The vehicle-document logger was worse. It asked for a model by a name with one extra letter. The call failed with “cannot read properties of undefined”, and the handler around it only printed the error to a console nobody reads. That happened 226 times without a sound.

We checked it was the only fault of its kind by cross-checking all 100 model names used in the code against the 72 registered. The other unregistered names were leftovers from code belonging to a different product.

What we changed

The “before” copy is now taken before the save, and two more fields (licence number and identity proof) are tracked. The misspelt name was corrected and the handler upgraded so a failure is recorded as a real error. On the test system we changed a customer’s rating and confirmed a log row now appeared.

What it did not fix

There is no history from before the fix. The 226 silent failures are gone for good, and the booking changes made while the logger was empty cannot be reconstructed from it.

One more reference to a model that does not exist was found in code from a different product and left alone, flagged for a decision on cleaning it up. The live server’s own error log also still had no timestamps and no rotation.

How to check your own audit log

An audit trail that has never been read is an assumption.

1. Make one change to each kind of record you rely on (a customer’s ID or bank details, an odometer reading, a vehicle document) and look for the line in the log. If there is none, the trail is decorative.
2. Ask your supplier whether the log records the record before and after the change, and when the “before” copy is taken. If it is taken after the save, the difference is always empty.
3. Ask what happens when logging itself fails: is it recorded as a real error somebody sees, or only printed somewhere nobody reads?
4. Treat an empty table next to a busy one as a finding, not as an absence of problems.
5. Accept that a fixed log has no history from before the fix.

Where this ends up

Change history the office can trust, recorded where the change happens, is part of what Sazinga Rentals keeps for each booking.