Glossary

AutoFlow is the product a user writes workflow definitions for. autocore is the durable engine underneath it, embedded in GitLab Relay (formerly KAS). The layer column says which one owns a term.

Term	Layer	Definition
Action	AutoFlow	A function a module exposes to a workflow definition. Calling one returns a future; the work runs outside the interpreter and its outcome is recorded.
Activity	autocore	A side-effecting function executed outside the deterministic replay, with its result written to history. Every action call becomes one.
Annotation	AutoFlow	A key and value tag the caller puts on a workflow at start. Every child workflow inherits the set, and every action invocation carries it.
autocore	autocore	The event-sourced workflow engine embedded in Relay: durable timers, activities, signals and cancellation, on PostgreSQL for state and Redis for coordination. It is generic; AutoFlow is one domain built on it.
Channel	AutoFlow	A stream of values a workflow receives from outside, created by `channel()` or bound to a `main()` parameter by the caller. Never closed, values arrive in the order AutoFlow received them.
Channel token	AutoFlow	A send-only capability for one channel of one workflow. It names no principal, so a send presents the workflow token as well.
Child workflow	AutoFlow	A workflow another workflow starts. `w.start_workflow()` is detached; `w.execute_workflow()` is awaitable and canceled if the parent terminates.
Cold replay and warm resume	autocore	Two ways a workflow continues. A cold replay re-runs the workflow definition from the top against the whole history because no suspended goroutine exists. A warm resume feeds only the newer events to a goroutine still in memory.
Derived action	AutoFlow	An action wrapped by a pure Starlark transform that runs where the action runs, so a response can be reshaped or classified without a round trip into the workflow.
Determinism	autocore	The requirement that a workflow takes the same decisions in the same order on every replay. A scheduling call that does not match the recorded one is a replay mismatch.
Durable timer	autocore	A sleep or timer persisted as a database row rather than held as a process timer, so a waiting workflow holds no CPU or memory.
Fence	autocore	A counter on a shard row, bumped on every ownership change and verified inside every write, so a former owner cannot corrupt a shard after it moves.
Future	AutoFlow	A handle to an asynchronous result: an action call, a timer, a poll or an awaitable child. Waited on with `gather` or watched with `select`; resolves once, to a permanent value. See Futures and gather.
History	autocore	The append-only log of one workflow’s life, one row per state change, with gapless sequence ids. Replaying it is what makes a workflow resumable.
Idempotency key	autocore	The caller-chosen key that pins one workflow per namespace, or one delivery per channel send. Resubmitting under a used key returns what already exists.
Inline activity	autocore	A cheap, idempotent side effect run inside the workflow’s own goroutine, with its outcome written as one history event. A failed attempt escalates to an ordinary queued activity.
Lease	autocore	The ownership record on a shard row: an owner and an expiry, renewed by heartbeat. An expired lease lets another instance claim the shard.
Module	AutoFlow	The unit that gives a workflow the ability to act outside itself. It exposes variables, actions and Starlark files, and a workflow definition imports them with `load("module:<name>", ...)`.
Module descriptor	AutoFlow	What a module publishes: its proto descriptor set, its variables, its actions and its files.
Namespace	autocore	The caller-supplied grouping every RPC carries. It scopes idempotency keys and the rate limit.
Poll	AutoFlow	Re-invoking an action on a fixed interval until a predicate over its result holds or a deadline passes. A result that does not satisfy the predicate, or a retryable error, re-pends the same activity task without a history event, so history stays flat however long the wait.
Relay	Relay	The GitLab server component, formerly KAS, whose binary hosts the AutoFlow module alongside the Kubernetes agent server, the job router and workspaces. It is where the code lives, not the actor.
Replay	autocore	Re-running a workflow definition from the top against the workflow’s recorded history. A call with a recorded outcome returns that outcome instead of doing the work again.
Retention	autocore	The window past which a workflow’s partitions are dropped, 90 days by default. It bounds idle time as well as cleanup: an idle non-terminal workflow is retired too.
Retry policy	autocore	The retry budget of an activity whose call fails or times out: 20 attempts by default, starting at one second, doubling, capped at ten minutes, about an hour and three quarters in all, every attempt under the same idempotency key. Attempts are counted on the activity task, not in history; the workflow sees only the final outcome.
Sensitive value	AutoFlow	A `sensitive_string` or `sensitive_bytes`. A workflow can pass it and concatenate it, but cannot read, hash or probe it, and cannot construct one from ordinary data.
Shard	autocore	The unit of partitioning. The keyspace of workflows is split into shards, and each shard is owned by at most one AutoFlow instance at a time.
Signal	autocore	An external message to a running workflow, written to an inbox and later promoted into a history event by the shard owner. A channel value is one.
Workflow	autocore	One durable run of a workflow definition, started by `StartWorkflow`.
Workflow definition	AutoFlow	The Starlark program a user writes. One definition can back many workflows.
Workflow key	autocore	The opaque public identifier of a workflow. It embeds the shard, so traffic after creation routes without a central lookup.
Workflow token	AutoFlow	The capability minted at start that every other RPC requires. Holding a workflow key or an idempotency key is not holding the workflow.

Last updated on September 12, 2026

Limits