Module event_log

Module event_log 

Source
Expand description

Append-only canonical event log (RFC-0005 §4.3 + the broader log pattern: PlanActions, Effects, gate decisions, verifications, manifest polls all land here too).

§Relationship to probe_failures

event_log is the sole canonical store — every PlanAction, Effect, GateDecision, and inbound agent event lands here exactly once. Indexed by seq, (host_id, ts), (rollout_id, seq), (kind, ts) for chronological / per-rollout / per-host / per-kind queries.

probe_failures (RFC-0007 §7.2) is a derived view carrying the typed denormalization the compliance-wave gate needs cheaply (probe_name, control_id, framework, observed_at indexed on (rollout_id, host_id, control_id)). Single writer: the applier’s RemoteAppendEventLog handler, on enforce-mode ProbeResult { status = Fail }, writes the event_log row AND the per-sub_result probe_failures rows in one transaction. Each probe_failures row carries an event_log_seq FK back to its source event_log entry — the table is provably re-derivable from canonical state and can be rebuilt by walking event_log from the beginning.

Phase 9a deleted the prior host_reports denormalization (its query patterns + dedup invariant moved to probe_failures + the event_log writer respectively).

Structs§

EventLog
EventLogEntry
EventLogRow

Enums§

EventLogKind
What kind of log entry. Disambiguates the JSON payload shape and drives the operator-API filters.

Functions§

row_to_entry 🔒