Emit Flow
Two ConnectRPC endpoints expose emit semantics:
PubSubService/Emit— fires an event, returns run IDs + event IDIronflowService/Emit(alias forTrigger) — same semantics, different request/response messages
Both delegate to the same core logic in eventtrigger.Helper.Emit(). Neither publishes to the pubsub bridge directly — the events:{name} message is enqueued once through the transactional outbox (issue #487), which is the single source subscribers and projections read. One transaction writes the event row and its outbox entry, so an invalid schema costs zero rows.
The call returns as soon as those rows are committed. Every matched function gets its own run, created waiting_for_capacity, and the caller gets the run IDs without waiting for any of them.
Functions are not the delivery mechanism. The outbox row is committed before trigger matching runs, so an event with no matching function is still stored and still published — emit() returns an empty run list, not an error. Subscribers and live projections receive the outbox publish either way. Workflow waitForEvent uses a separate path: DispatchMatched passes the event directly to the scheduler, which satisfies database correlations without waiting for the outbox or nats_seq.
Dispatch does not fork on mode. Since ADR 0037 (#1206) every runnable run — push and pull — is admitted to the DB-backed dispatch_queue; there is no direct-dispatch bypass. The modes differ only after admission: a push run takes the synchronous fast-path and executes inline once its concurrency lane has room, while a pull run is never run inline and waits for a worker to claim it.
The event row itself is never deleted. It is inserted with processed=false, and MarkEventProcessed() flips it to true once its runs have been created and dispatched — the row stays in the database as the audit trail either way.
That admission path, from ingress through the lease to completion, is drawn in full on the Request Lifecycle diagram. To wait on the runs instead of returning, see EmitSync Flow.