Several write paths saved the change first and recorded the audit entry afterwards. If that second step failed, the change was already in place, the request answered with an error, and nothing in the audit log said it had happened.

Creating, updating or deleting an environment, updating a vault, configuring a dynamic secret role, issuing a dynamic credential and revoking one (manually or on expiry) now write the audit entry in the same transaction as the change. Both are saved together or neither is.

Issuing a dynamic credential also cleans up after itself: if the lease or its audit entry cannot be saved, the database user created for it is dropped again, so no credential exists that the audit log and the lease list do not show.

Nothing changes in the API. A request that used to fail late with a leftover change now fails cleanly, and can be retried.