Minor Description
The algorithm currently is to execute all queued PersistenceCommands (corresponding to container.persist() or container.remove()) in order. However, if the isis-module-audit module is configured, then, if an object execute a transaction flush (as the result of obtaining a pre- value) this can result in executing the same command all over.
In the particular case I investigated it resulted in double processing of a delete command; on the second time around I got "cannot read from deleted object" even though was ostensibly in the "preDelete" callback.
The required fix is a minor change to the way in which the command list are queued to ensure that both (a) each command is executed precisely once while (b) still allowing for additional commands to be added to the end of the command list should that occur.
~~~~
There is also a very similar issue in the way in which the changedObjectProperties are iterated over during preCommit; it's possible that this collection might be added to while obtaining the post values of all objects.