Ironflow Event Fan-Out

Ironflow Event Fan-Out A data-flow diagram generated by Archify. 01 / Call 02 / Commit 03 / Fan-out 04 / Transport 05 / Observers emit() · schema checked · 01 / Call emit() schema checked append() · CAS on version · 01 / Call append() CAS on version One transaction · event + outbox rows · 02 / Commit · nothing published yet One transaction event + outbox rows nothing published yet Match triggers · in-process · 03 / Fan-out Match triggers in-process Outbox rows · 1 emit, 2 append · 03 / Fan-out Outbox rows 1 emit, 2 append PUBSUB · public.{envID}.> · 04 / Transport PUBSUB public.{envID}.> Runs · one per match · 05 / Observers Runs one per match Subscribers · SDK, dashboard · 05 / Observers Subscribers SDK, dashboard Projections · consume by name · 05 / Observers Projections consume by name 1 outbox row 2 outbox rows after commit same transaction outbox worker drains one run per match events.{name} tracks a cursor Legend primary data data store data flow

Triggers are one consumer, not the delivery

  • • The outbox row commits before DispatchMatched runs, so it needs no match
  • • Zero matching functions returns an empty run list, not an error
  • • Before #487 non-entity emit never reached NATS at all

What append adds

  • • Two outbox rows: entity:{type}.{id}.{name} plus events:{name}
  • • The entity row is patched with the version assigned inside the txn
  • • A version conflict writes neither row — no orphan NATS message

Delivery outside the outbox

  • • append() also fires system.stream.{entityId}.appended (#1730)
  • • That notification has no retry or dead-letter queue
  • • waitForEvent uses scheduler DB correlations via DispatchMatched; no nats_seq dependency