Struct EventCtx 

pub struct EventCtx<'inv, B = ()> { /* private fields */ }

Per-event decision point handed to handle_persistent.

Generic over the handler’s Batch accumulator B (defaulting to () for handlers that never collect). See the module docs for the semantics of the four entry verbs.

Implementations

impl<'inv, B> EventCtx<'inv, B>

pub fn skip(self) -> Handled<'inv>

This event is not for me — no transaction is opened, an open batch op is left untouched, and the checkpoint advances lazily (piggybacked on the next flush, or persisted on the configured checkpoint interval).

pub fn collect_with(self, f: impl FnOnce(&mut B)) -> Handled<'inv>

Contribute to the pending batch’s accumulator — a pure memory write: no transaction is opened and no statement is executed now. The runner hands the accumulated batch to the handler’s flush exactly once per batch landing, inside the transaction that commits the checkpoint.

Like defer, collected work shares fate with its neighbors and must tolerate whole-batch replay: on a failed flush the events replay and their items are re-collected.

For Vec and HashMap accumulators the collect sugar is usually more convenient.

pub async fn consume_in_batch( self, ) -> Result<BatchOp<'inv>, Box<dyn Error + Send + Sync>>

Do transactional work joined to the pending batch op (opening a fresh one if none is pending).

Work in a batch shares fate with its neighbors: a failure anywhere in the batch rolls back and replays the whole batch from the last committed checkpoint. Only choose this when the handler’s work is idempotent under such replay (pure in-op DB writes and in-op job spawns are — they roll back with the op).

pub async fn consume_isolated( self, ) -> Result<IsolatedOp<'inv>, Box<dyn Error + Send + Sync>>

where B: Default,

Land the pending batch first (its collected items, its work and its checkpoint, at the last fully handled sequence), then hand back a fresh op: this event is its own atomic unit, sharing no fate with history — and none with the future either, since IsolatedOp only offers commit.

This is the failure-isolation fence: if this event’s work fails, only this event replays; and it is the exact legacy per-event semantics when no batch is pending.

impl<'inv, T> EventCtx<'inv, Vec<T>>

pub fn collect(self, item: T) -> Handled<'inv>

collect_with sugar for Vec accumulators: append one item to the pending batch.

impl<'inv, K, V, S> EventCtx<'inv, HashMap<K, V, S>>

where K: Hash + Eq, S: BuildHasher,

pub fn collect(self, key: K, value: V) -> Handled<'inv>

collect_with sugar for HashMap accumulators: keyed last-write-wins insert. Persistent events arrive in ascending sequence, so within a batch this naturally keeps the newest item per key — the coalescing fold (N updates per key → 1 flushed entry).