Request Lifecycle

Shows the full path of an emit() call from client to completion. The server validates the event against its registered schema, writes the event row and its outbox entry in one transaction, matches the event against registered function triggers, and creates one run per match — each starting in waiting_for_capacity.

Execution does not fork on mode at that point. Push and pull runs both enter the same DB-backed dispatch_queue: admission resolves the run’s concurrency lane and allocates its execution_seq, then the dispatcher reserves the segment against the cluster-wide lane counter and mints a fenced lease. Only after the lease exists do the transports diverge — push posts to your endpoint inline, while a pull worker claims the fenced job over a gRPC stream or a REST long-poll. Completion transitions the run and releases the lease, which frees the lane for the next segment.