Module store 

Persistence.

The execution_events table is the source of truth. workflow_executions is a projection kept in the same transaction for fast listing. Every batch of events is appended atomically together with the projection update. execution_events holds each execution’s current run; runs that ended with continue-as-new are moved to execution_run_events (keyed by run) in the transaction that starts the next run. orbit_schedules holds the schedules (see crate::schedule).

Two backends share the schema and the guarantees:

• SQLite (default): a single file, WAL mode, synchronous=FULL.
• PostgreSQL: pass a postgres:// URL. All statements run on one dedicated connection thread, so the synchronous engine never blocks the async server runtime from inside it, and the connection is re-established automatically if it drops.

Structs

ExecutionSummary

FireRecord

The outcome of firing one occurrence, written when the firing server releases its claim (see Store::finish_schedule_fire).

PgStore

Rollover

Continue-as-new: the finished run’s number and its last events. They are archived, together with the rest of that run’s history, in the transaction that writes the next run’s first events.

ScheduleRow

A schedule as stored in orbit_schedules. spec is the JSON of crate::schedule::ScheduleSpec; the other columns are the schedule’s progress, written by whichever server fires it.

SqliteStore

StoreError

A storage error from either backend.

WorkerRecord

Enums

PgMode

How a PgStore may write. Single-node servers use ReadWrite; the cluster mode (orbit server --cluster, see crate::cluster) gives a standby a ReadOnly store and the leader a Fenced one.

PutDefinition

Store

The storage backend used by the engine.

Type Aliases

Result