Struct AppendResult 

pub struct AppendResult {
    pub seq: u64,
    pub idempotent_replay: bool,
    pub applied: bool,
    pub prior: Option<PriorEvent>,
}

Outcome of an append_and_apply_event call.

seq is the value a caller surfaces to a user: the freshly appended event’s seq, or — on an idempotent replay — the seq of the pre-existing matching event. A reducer no-op (e.g. an event dropped by the terminal-state guard) is still a success at this layer: seq names the appended event regardless of whether the reducer changed anything.

There is intentionally no derived_event_ids field. This API mutates exactly one event; the supervisor’s report consumption, which emits a batch of derived discussion/spinoff events under one held lock, uses append_and_apply_unlocked instead (the sanctioned lock-held composition path) and tracks its own emitted ids.

Fields

seq: u64

seq of the appended event, or of the prior event on an idempotent replay.

idempotent_replay: bool

True when idempotency_key matched a prior event so nothing new was appended or applied; seq/prior then describe that prior event.

applied: bool

True when the reducer produced at least one projection write for THIS append — i.e. the event actually changed state, rather than folding to a no-op (an unknown/audit kind, or an event dropped by a *.created / terminal-state guard). Lets a caller distinguish “the reducer applied my event” from “it was a dead event” WITHOUT re-reading the projection and pattern-matching a field (issue reducer-adopt-explicit-merge).

This is a report of what the reducer did on THIS call, NOT a durable “is teardown pending?” signal: it is false both on an idempotent replay AND on a fresh append the reducer no-op’d (e.g. re-submitting the exact report already adopted). Callers making a DURABLE decision (does the run still need a teardown actor?) must read projection state, not this flag — see run merge’s ensure_report_consumer, which deliberately does NOT gate its reattach on applied (that was a crash-retry leak caught in review).

prior: Option<PriorEvent>

On an idempotent replay, the prior event’s recorded node_id and data, so a caller can reject a key reused with a conflicting request (Stripe-style). None on a fresh append.

Trait Implementations

impl Debug for AppendResult

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Serialize for AppendResult

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.