Skip to main content

Module audit

Module audit 

Source
Expand description

Audit log primitives.

The audit subsystem is split into a record format (here, backend-agnostic) and a sink trait. The canonical store is a table inside the same database as the mutation, written inside the same transaction so audit events never drift from the data they describe. Downstream fan-out (Kafka, Redis pubsub, HTTP webhook) goes through an AuditSink implementation; the table itself remains the source of truth for compliance review.

Structs§

AuditActor
AuditEvent
MulticastAuditSink
Fan an audit event out to multiple sinks. Errors from any individual sink are aggregated into CoolError::Internal so a single failing downstream does not silently swallow problems with the others.
NoopAuditSink
Default sink that does nothing. The in-database audit table is treated as authoritative; downstream consumers are added by wrapping a different sink (or composing several).

Enums§

AuditOperation
TransactionIsolation
Transaction isolation level requested by a procedure via @isolation(...). Mirrors the PostgreSQL spec: lower variants tolerate more anomalies, higher ones cost more under contention. Banks running multi-row updates (transfers, postings) typically pick Serializable and pair it with retry-on-serialization-failure.

Traits§

AuditSink
Pluggable audit sink. Implementations fan audit events out to downstream systems (Kafka topics, Redis pubsub, HTTP webhooks, S3 buckets) for long-term retention or SIEM ingestion. The in-database audit table written by cratestack_sqlx remains the canonical record; sinks are best-effort projections.