Glossary All reference terms, including SDK, Restate, Effect, and shared vocabulary. Package ownership is recorded for a subset; related reading does not imply ownership.
Find a term, definition, or owning package
Temporal A runtime for "reentrant processes": functions whose state and progress survive process and host failure because the server records every step and can replay them on any worker. The platform is the server (four services plus persistence) and the workers you run. https://docs.temporal.io/temporal
No package ownership mapping recorded; use the reference sources below.
In comparison reference Durable Execution The property that a Workflow Execution keeps its state and progress across failures. Implemented by journaling the results of non-deterministic steps and replaying the code against that journal. https://docs.temporal.io/temporal#durable-execution
No package ownership mapping recorded; use the reference sources below.
In comparison reference Temporal Platform / Temporal Application The Platform is a Temporal Service plus Worker Processes. An Application is the set of Workflow Executions your code produces. https://docs.temporal.io/temporal#temporal-platform
No package ownership mapping recorded; use the reference sources below.
In comparison reference Temporal Service (formerly Temporal Cluster) A Temporal Server paired with a Persistence store (Cassandra, MySQL, Postgres, SQLite) and a Visibility store. "Cluster" is being phased out in favour of "Service". https://docs.temporal.io/temporal-service
Restate: a Restate cluster: nodes with roles, the replicated log, the metadata store, and optional object store for snapshots. https://docs.restate.dev/server/clusters
Effect: a SQL database plus any number of runners. E/cluster/SqlMessageStorage.ts
Owning packages: common/persistence · common/persistence/client · common/persistence/serialization · common/persistence/cassandra · common/persistence/sql · common/persistence/sql/sqlplugin · common/persistence/schema · api/persistence/v1
In comparison reference Temporal Server The four horizontally scalable services (Frontend, History, Matching, Worker) that together implement the server. https://docs.temporal.io/temporal-service/temporal-server
Owning packages: temporal · cmd/server
In comparison reference Frontend Service The stateless gRPC (and HTTP) gateway. It authenticates, rate-limits, validates the Namespace, and routes each call to the right History shard or Matching partition. All SDK traffic goes through it. https://docs.temporal.io/temporal-service/temporal-server#frontend-service
Restate: the HTTP ingress role (port 8080) for invocations and the admin role (port 9070) for control-plane calls. https://docs.restate.dev/services/invocation/http
Effect: WorkflowProxy / EntityProxy HTTP or RPC groups served by any runner. E/workflow/WorkflowProxy.ts
Owning packages: service/frontend · service/frontend/configs · common/rpc/interceptor
In comparison reference History Service The stateful core. It owns Workflow Execution state (mutable state and Event History), decides what to do next, and runs the internal task queues (transfer, timer, visibility, outbound, replication). Scaled by History Shards. https://docs.temporal.io/temporal-service/temporal-server#history-service
Restate: the worker role, i.e. partition processors applying the log into RocksDB. https://docs.restate.dev/references/architecture
Effect: the shard-owning runner's entity manager plus the cluster workflow engine. E/cluster/ClusterWorkflowEngine.ts
Owning packages: service/history · service/history/api · service/history/configs · api/historyservice/v1
In comparison reference History Shard A fixed-count partition of the execution space. Each shard is owned by exactly one History host at a time and is the unit of throughput scaling. Shard count cannot be changed after the cluster is created. https://docs.temporal.io/temporal-service/temporal-server#history-shard
Restate: a partition (default 24), a key range of the 64-bit partition key space, owned by a leader replica. https://docs.restate.dev/server/clusters
Effect: a shard (300 per shard group), a hash bucket of entity IDs, owned by a runner holding its lease. E/cluster/ShardingConfig.ts
Owning packages: service/history/shard · client/history · common/persistence
In comparison reference Matching Service Hosts Task Queues. It matches tasks produced by History to Worker long-polls, either in memory (sync match) or via a persisted backlog. https://docs.temporal.io/temporal-service/temporal-server#matching-service
Restate: no analogue; the server pushes to the endpoint.
Effect: no analogue; messages are addressed directly to the owning runner.
Owning packages: service/matching · service/matching/configs · api/matchingservice/v1
In comparison reference Worker Service The server-side service that runs system Workflows (scanner, batch operations, schedules V1, worker deployments, migrations) and other background jobs using the Go SDK against the Frontend. https://docs.temporal.io/temporal-service/temporal-server#worker-service
Restate: admin role plus leader-side background tasks (cleaner, log trimmer, durability tracker). https://docs.restate.dev/server/overview
Effect: no analogue beyond the runner-health singleton. E/cluster/RunnerHealth.ts
Owning packages: service/worker · service/worker/scanner · service/worker/batcher · service/worker/migration · service/worker/dlq
In comparison reference Namespace The unit of isolation. Workflow IDs, Task Queues, retention, search attributes, and replication settings are scoped per Namespace. https://docs.temporal.io/namespaces
Restate: no analogue within one cluster; isolation is per cluster.
Effect: no analogue; shard groups are only a placement knob. E/cluster/ClusterSchema.ts
Owning packages: common/namespace · common/namespace/nsregistry · common/namespace/nsmanager · service/frontend · api/namespace/v1
In comparison reference Temporal Service configuration The YAML config for a self-hosted server (persistence, services, membership, TLS, archival), separate from dynamic config. https://docs.temporal.io/temporal-service/configuration
Owning packages: common/config · temporal · temporal/environment
In comparison reference Workflow Day-to-day shorthand for Workflow Type, Workflow Definition, or Workflow Execution. https://docs.temporal.io/workflows
Restate: a handler on a Service, Virtual Object, or Workflow, depending on whether it is keyed and single-run. https://docs.restate.dev/foundations/services
Effect: a Workflow.make(...) definition or one of its executions. E/workflow/Workflow.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Workflow Definition The user code that defines a Workflow. It must be deterministic: on replay it must issue the same Commands in the same order. Non-deterministic work goes in Activities. https://docs.temporal.io/workflow-definition
Restate: the handler function. Determinism is not required by the SDK; a divergence on replay is detected as a journal mismatch. https://docs.restate.dev/develop/ts/services
Effect: the handler passed to Workflow.toLayer. Determinism is neither required nor detected. E/workflow/Workflow.ts
Owning packages: sdk
In comparison reference Workflow Type The name that maps to a Workflow Definition, used when starting executions and registering workers. https://docs.temporal.io/workflow-definition#workflow-type
No package ownership mapping recorded; use the reference sources below.
In comparison reference Workflow Execution One durable run of a Workflow Definition, identified by Workflow ID plus Run ID. It is the main unit of execution: it has an Event History, can be signalled, queried, updated, and can spawn Activities and children. https://docs.temporal.io/workflow-execution
Owning packages: service/history/workflow · service/history/api/startworkflow · service/history/api/describeworkflow · service/history/api/terminateworkflow
In comparison reference Workflow ID A user-chosen, application-level identifier. Within a Namespace, at most one execution with that ID can be open at a time, which is how Temporal provides entity-style uniqueness. https://docs.temporal.io/workflow-execution/workflowid-runid#workflow-id
Owning packages: service/history/api/startworkflow · common/persistence
In comparison reference Run ID A platform-generated, globally unique ID for one run of a Workflow ID. Continue-As-New, retries, cron, and reset all produce new Run IDs under the same Workflow ID. https://docs.temporal.io/workflow-execution/workflowid-runid#run-id
Owning packages: service/history/api/startworkflow · service/history/workflow
In comparison reference Workflow ID Reuse Policy Controls whether a new execution may reuse a Workflow ID that belongs to a closed execution (allow, allow only if the previous failed, reject). https://docs.temporal.io/workflow-execution/workflowid-runid#workflow-id-reuse-policy
Restate: a repeat request with the same idempotency key returns the stored result until journal retention expires; no per-start policy. https://docs.restate.dev/services/invocation/http
Effect: no analogue; the same payload always maps to the same execution.
Owning packages: service/history/api/startworkflow
In comparison reference Workflow ID Conflict Policy Controls what happens when starting a Workflow ID that is currently running: fail, return the existing run, or terminate the existing run and start fresh. https://docs.temporal.io/workflow-execution/workflowid-runid#workflow-id-conflict-policy
Restate: a duplicate idempotent request attaches to the running invocation; exclusive Virtual Object handlers queue behind each other. https://docs.restate.dev/services/invocation/http
Effect: execute on a running execution attaches and polls for its result. E/workflow/WorkflowEngine.ts
Owning packages: service/history/api/startworkflow · service/history/api/multioperation
In comparison reference Continue-As-New Closes the current run and atomically starts a new run of the same Workflow ID with a fresh Event History and the state you pass along. Used to bound history size for long-lived workflows. https://docs.temporal.io/workflow-execution/continue-as-new
Restate: not needed; the journal is per invocation and is trimmed on completion. Long-lived state belongs in Virtual Object K/V. https://docs.restate.dev/develop/ts/state
Effect: no analogue; replay cost grows with step count.
Owning packages: service/history/workflow · service/history/api/respondworkflowtaskcompleted
In comparison reference Child Workflow A Workflow Execution started from inside another. The parent gets the child's result as an Event and can control what happens to the child when the parent closes. https://docs.temporal.io/child-workflows
Owning packages: service/history/queues · service/history/api/recordchildworkflowcompleted · service/history/api/verifychildworkflowcompletionrecorded
In comparison reference Parent Close Policy What happens to a child when its parent closes: terminate, request cancel, or abandon. https://docs.temporal.io/parent-close-policy
Owning packages: service/worker/parentclosepolicy · service/history/queues
In comparison reference Delay Workflow Execution A start option that delays the first Workflow Task by a duration. https://docs.temporal.io/workflow-execution/timers-delays
Owning packages: service/history/api/startworkflow · service/history/queues
In comparison reference Temporal Cron Job A legacy way to run a Workflow on a cron spec by chaining runs under one Workflow ID. Schedules supersede it. https://docs.temporal.io/cron-job
Owning packages: service/history/workflow · service/history/queues
In comparison reference Schedule A first-class server resource that starts Workflow Executions on a calendar or interval spec, with pause, backfill, overlap policies, and jitter. https://docs.temporal.io/schedule
Owning packages: service/worker/scheduler · chasm/lib/scheduler · service/worker/scanner/scheduleinvariants · api/schedule/v1
In comparison reference Reset Terminates an execution and starts a new run from a chosen point in its Event History, discarding later progress. https://docs.temporal.io/workflow-execution/event#reset
Owning packages: service/history/api/resetworkflow · service/history/ndc · service/history/api/reapplyevents
In comparison reference State Transition One unit of progress of a Workflow Execution, as counted by the server (used for Cloud billing and the transition count clock). https://docs.temporal.io/workflow-execution#state-transition
Owning packages: service/history/workflow · common/persistence/transitionhistory
In comparison reference Retention Period How long a closed execution's Event History stays in persistence before deletion (default 72 hours on self-hosted). https://docs.temporal.io/temporal-service/temporal-server#retention-period
Owning packages: service/history/deletemanager · service/history/queues · service/history/workflow
In comparison reference Archival A self-hosted feature that copies closed Event Histories and visibility records to blob storage after retention expires. https://docs.temporal.io/temporal-service/archival
Owning packages: common/archiver · common/archiver/provider · common/archiver/filestore · common/archiver/s3store · common/archiver/gcloud · service/history/archival · api/archiver/v1
In comparison reference Workflow History Export Temporal Cloud feature exporting closed histories to a customer storage sink. https://docs.temporal.io/cloud/export
Restate / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Memo Non-indexed, user-supplied metadata attached to an execution and returned by describe and list. https://docs.temporal.io/workflow-execution#memo
Owning packages: service/history/workflow · common/persistence/visibility
In comparison reference Workflow cache The worker-side in-memory cache of Workflow Executions that lets Sticky Execution skip replay. https://docs.temporal.io/workflow-execution#workflow-cache
Restate: no SDK-side cache; the server pushes the journal each attempt.
Effect: the resident WorkflowInstance per entity. E/workflow/WorkflowEngine.ts
Owning packages: sdk
In comparison reference Event A record the server writes into Event History, either from an external occurrence (a Signal arrived, a timer fired) or from a Command the workflow issued. https://docs.temporal.io/workflow-execution/event#event
Owning packages: service/history/historybuilder · service/history/events · api/history/v1
In comparison reference Event History The append-only log of Events for one execution. It is the full state of the execution and is what workers replay. https://docs.temporal.io/workflow-execution/event#event-history
Owning packages: common/persistence · service/history/events · service/history/api/getworkflowexecutionhistory · service/history/api/getworkflowexecutionrawhistoryv2
In comparison reference Command A requested action a worker returns after a Workflow Task: schedule an Activity, start a timer, signal another workflow, complete the workflow. The server validates it and writes Events. https://docs.temporal.io/workflow-execution#command
Owning packages: service/history/workflow · service/history/api/respondworkflowtaskcompleted
In comparison reference Task The context a worker needs to make progress on one execution: either a Workflow Task or an Activity Task. https://docs.temporal.io/tasks#task
No package ownership mapping recorded; use the reference sources below.
In comparison reference Workflow Task A Task telling a worker to advance a Workflow Execution. It carries the Event History (or the delta since the sticky cache) and expects Commands back. https://docs.temporal.io/tasks#workflow-task
Owning packages: service/history/workflow · service/history/api/scheduleworkflowtask · service/history/api/recordworkflowtaskstarted · service/history/api/respondworkflowtaskcompleted · service/history/api/respondworkflowtaskfailed · service/matching
In comparison reference Workflow Task Execution A worker picking up a Workflow Task, replaying history in the sandbox, running the code until it blocks, and responding with Commands. https://docs.temporal.io/tasks#workflow-task-execution
No package ownership mapping recorded; use the reference sources below.
In comparison reference Workflow Task Timeout The maximum time the server waits for a worker to start processing a Workflow Task before rescheduling it (default 10 seconds). https://docs.temporal.io/encyclopedia/detecting-workflow-failures#workflow-task-timeout
Owning packages: service/history/queues · service/history/workflow
In comparison reference Activity Task A Task carrying the input and context for one Activity attempt. https://docs.temporal.io/tasks#activity-task
Owning packages: service/history/queues · service/matching · service/history/api/recordactivitytaskstarted · service/history/api/isactivitytaskvalid
In comparison reference Activity Task Execution One attempt of running an Activity Definition with the Activity Task's context. https://docs.temporal.io/tasks#activity-task-execution
Restate: one execution of a ctx.run closure.
Effect: one run of an Activity's execute. E/workflow/Activity.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Task Token An opaque identifier for one Activity Task Execution, used to complete it asynchronously or send heartbeats from outside the worker. https://docs.temporal.io/activity-execution#task-token
Owning packages: common/tasktoken · api/token/v1
In comparison reference Side Effect A way to run a short non-deterministic snippet inside workflow code and record its result as an Event so replay reuses it. No retries, no separate task. https://docs.temporal.io/workflow-execution/event#side-effect
Owning packages: sdk · service/history/workflow
In comparison reference Activity Shorthand for Activity Type, Definition, or Execution: the unit of non-deterministic, retryable work. https://docs.temporal.io/activities
No package ownership mapping recorded; use the reference sources below.
In comparison reference Activity Definition The function that implements an Activity. It may do anything: I/O, randomness, long blocking calls. The server retries it per Retry Policy. https://docs.temporal.io/activity-definition
Restate: the closure passed to ctx.run.
Effect: the execute Effect.
Owning packages: sdk
In comparison reference Activity Type The name mapping to an Activity Definition. https://docs.temporal.io/activity-definition#activity-type
Restate: the optional ctx.run(name, ...) label.
Effect: the Activity name, part of the dedup key.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Activity Execution The full chain of attempts for one scheduled Activity, from schedule to final result. https://docs.temporal.io/activity-execution
Restate: all attempts of one Run journal entry.
Effect: all attempts of one Activity name.
Owning packages: service/history/workflow · service/history/api/respondactivitytaskcompleted · service/history/api/respondactivitytaskfailed · service/history/api/respondactivitytaskcanceled · service/history/api/pauseactivity · service/history/api/resetactivity · service/history/api/updateactivityoptions
In comparison reference Activity ID The unique ID of an Activity Execution within its workflow. https://docs.temporal.io/activity-execution#activity-id
Restate: the journal entry index.
Effect: name plus attempt.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Workflow Activity An Activity orchestrated by a Workflow, as opposed to a Standalone Activity. https://docs.temporal.io/workflow-activity
Restate: any ctx.run or Call inside a handler.
Effect: any Activity inside a workflow body.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Standalone Activity An Activity started directly from a client with no enclosing workflow, backed by CHASM. https://docs.temporal.io/standalone-activity
Owning packages: chasm/lib/activity · chasm/lib/activity/model · service/frontend
In comparison reference Local Activity An Activity executed inside the worker's workflow task, skipping the Task Queue round trip. Cheaper but bounded by the Workflow Task Timeout. https://docs.temporal.io/local-activity
Owning packages: sdk · service/history/workflow
In comparison reference Asynchronous Activity Completion An Activity returns "will complete later" and an external system completes it by Task Token. https://docs.temporal.io/activity-execution#asynchronous-activity-completion
Owning packages: service/frontend · service/history/api/respondactivitytaskcompleted · common/tasktoken
In comparison reference Activity Heartbeat A periodic ping from the worker running an Activity, carrying optional progress details, so the server can detect a dead worker and the Activity can resume from the last heartbeat. https://docs.temporal.io/encyclopedia/detecting-activity-failures#activity-heartbeat
Restate: no analogue; the invoker holds the open stream and detects disconnect.
Effect: no analogue.
Owning packages: service/history/api/recordactivitytaskheartbeat · service/history/queues
In comparison reference Heartbeat Timeout Max time between heartbeats before the server fails the attempt. https://docs.temporal.io/encyclopedia/detecting-activity-failures#heartbeat-timeout
Owning packages: service/history/queues · service/history/workflow
In comparison reference Schedule-To-Start Timeout Max time an Activity Task may wait in a Task Queue before a worker picks it up. Usually left unset. https://docs.temporal.io/encyclopedia/detecting-activity-failures#schedule-to-start-timeout
Restate / Effect: no analogue (no queue between engine and code).
No package ownership mapping recorded; use the reference sources below.
In comparison reference Start-To-Close Timeout Max duration of one Activity attempt. Required unless Schedule-To-Close is set. https://docs.temporal.io/encyclopedia/detecting-activity-failures#start-to-close-timeout
No package ownership mapping recorded; use the reference sources below.
In comparison reference Schedule-To-Close Timeout Max duration for the whole Activity Execution including retries. https://docs.temporal.io/encyclopedia/detecting-activity-failures#schedule-to-close-timeout
No package ownership mapping recorded; use the reference sources below.
In comparison reference Retry Policy Server-side retry attributes: initial interval, backoff coefficient, max interval, max attempts, non-retryable error types. Applied to Activities by default and to Workflows if set. https://docs.temporal.io/encyclopedia/retry-policies
Restate: per-service retry policy (initial interval, exponentiation factor, max attempts, max interval, pause-or-kill on exhaustion) plus RunOptions for ctx.run. https://docs.restate.dev/services/configuration
Effect: Activity.retry (opt-in) and interruptRetryPolicy (on by default). E/workflow/Activity.ts
Owning packages: common/retrypolicy · common/backoff · service/history/workflow · service/history/queues
In comparison reference Idempotency Designing Activities so repeating them has the same effect as running once, which is required because delivery is at-least-once. https://docs.temporal.io/activity-definition#idempotency
Restate: same requirement for ctx.run; idempotency keys and awakeable IDs help. https://docs.restate.dev/guides/durable-webhooks
Effect: Activity.idempotencyKey supplies a stable key; WithTransaction gives exactly-once for same-DB effects. E/workflow/Activity.ts
Owning packages: sdk
In comparison reference Signal An asynchronous, fire-and-forget message to a running execution. It is written as an Event and triggers a Workflow Task; the workflow handles it with a registered handler. https://docs.temporal.io/sending-messages#sending-signals
Owning packages: service/history/api/signalworkflow · service/history/queues · service/history/api/removesignalmutablestate
In comparison reference Signal-With-Start Atomically start the execution if absent, then deliver a Signal. https://docs.temporal.io/sending-messages#signal-with-start
Restate: calling a Virtual Object creates it implicitly; for Workflows, submit run then call a shared handler. https://docs.restate.dev/foundations/services
Effect: execute plus a deferred completion, with no atomicity across the two.
Owning packages: service/history/api/signalwithstartworkflow · service/history/api/multioperation
In comparison reference Query A synchronous, read-only request answered by a worker from its cached workflow state. It writes no Events and cannot change state. https://docs.temporal.io/sending-messages#sending-queries
Owning packages: service/history/api/queryworkflow · service/history/workflow · service/matching
In comparison reference Update A synchronous request-and-response to a running execution that may mutate state. It has validation, accepted, and completed phases, and the caller can wait for either. https://docs.temporal.io/sending-messages#sending-updates
Owning packages: service/history/workflow/update · service/history/api/updateworkflow · service/history/api/pollupdate · common/protocol
In comparison reference Dynamic Handler A catch-all Workflow, Activity, Signal, or Query handler invoked when no registered name matches. https://docs.temporal.io/dynamic-handler
Restate / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Timer Durable, deterministic time APIs inside workflow code (sleep, timeouts on condition). The server fires them even if no worker is running. https://docs.temporal.io/workflow-execution/timers-delays
Owning packages: service/history/queues · service/history/workflow · common/timer
In comparison reference Workflow Execution Timeout Max total time for a Workflow ID across all runs, including retries and Continue-As-New. https://docs.temporal.io/encyclopedia/detecting-workflow-failures#workflow-execution-timeout
Restate / Effect: no analogue.
Owning packages: service/history/queues · service/history/workflow
In comparison reference Workflow Run Timeout Max time for one run. https://docs.temporal.io/encyclopedia/detecting-workflow-failures#workflow-run-timeout
Owning packages: service/history/queues · service/history/workflow
In comparison reference Worker Shorthand for Worker Program or Worker Process: the thing that runs your code. https://docs.temporal.io/workers#worker
Owning packages: sdk · service/matching/workers · common/workercommands
In comparison reference Worker Process A long-running process that polls Task Queues, executes workflow and activity code, and reports results. https://docs.temporal.io/workers#worker-process
No package ownership mapping recorded; use the reference sources below.
In comparison reference Worker Entity One worker within a process, bound to one Task Queue and one Namespace. https://docs.temporal.io/workers#worker-entity
Restate: one service registered on an endpoint.
Effect: one Entity registration in a runner. E/cluster/Entity.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Worker Program The static code that defines the Worker Process (which workflows and activities it hosts). https://docs.temporal.io/workers#worker-program
Restate: restate.endpoint().bind(...).
Effect: the Layer built from Workflow.toLayer and entity layers.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Task Queue A lightweight, dynamically created FIFO queue that workers poll. It is the routing key between server and workers; workflows and activities name one at schedule time. https://docs.temporal.io/task-queue
Owning packages: service/matching · common/tqid · common/taskqueue · common/persistence · api/taskqueue/v1
In comparison reference Task Routing Using distinct Task Queues to send specific Activities to specific workers (for example, host-specific or GPU-bearing). https://docs.temporal.io/task-routing
Owning packages: service/matching · sdk
In comparison reference Worker Session A Go SDK feature to run a sequence of Activities on the same worker without hand-naming a Task Queue. https://docs.temporal.io/task-routing#worker-session
Owning packages: sdk
In comparison reference Sticky Execution After a worker processes a Workflow Task, the server routes subsequent tasks for that execution to a worker-specific Task Queue so the cached state is reused instead of replaying from scratch. https://docs.temporal.io/sticky-execution
Owning packages: service/matching · service/history/api/resetstickytaskqueue · common/tqid · sdk
In comparison reference Nexus RPC An open protocol for arbitrary-duration operations with both synchronous and asynchronous completion, designed so durable executions can call across service and namespace boundaries. https://github.com/nexus-rpc/api/blob/main/SPEC.md
Owning packages: common/nexus/nexusrpc · common/nexus
In comparison reference Nexus Service A named collection of Nexus Operations forming a service contract. https://docs.temporal.io/nexus/services
Owning packages: service/frontend · service/matching · sdk
In comparison reference Nexus Operation One operation in a Nexus Service; may complete synchronously or return an operation token and complete later via callback. https://docs.temporal.io/nexus/operations
Owning packages: service/history/hsm/nexusoperations · service/history/hsm/nexusoperations/workflow · chasm/lib/nexusoperation · service/history/queues
In comparison reference Nexus Operation Handler Handler code in a worker implementing an Operation. https://docs.temporal.io/nexus/operations
Restate: a handler function.
Effect: an RPC handler.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Temporal Operation Handler A handler kind that backs an Operation with a Workflow, Update, or Activity, giving durable execution on the handler side. https://docs.temporal.io/nexus/temporal-operation-handler
No package ownership mapping recorded; use the reference sources below.
In comparison reference Nexus Standalone Activity An Operation backed by a Standalone Activity that completes when the activity returns. https://docs.temporal.io/nexus/standalone-activity
Restate: a plain Service handler.
Effect: an entity RPC.
Owning packages: chasm/lib/activity · chasm/lib/nexusoperation
In comparison reference Nexus Endpoint A named reverse proxy that routes a Nexus Service to a target Namespace and Task Queue (or an external URL). Callers reference endpoints, not workers. https://docs.temporal.io/nexus/endpoints
Owning packages: common/nexus · service/frontend · common/persistence
In comparison reference Nexus Registry The cluster-wide store of Endpoints, owned by one Matching node and polled by others. https://docs.temporal.io/nexus/registry
Owning packages: common/nexus · service/matching · common/persistence
In comparison reference Nexus Machinery The built-in at-least-once delivery of Operation start, cancel, and completion across Namespace boundaries (outbound queue, callbacks, retries). https://docs.temporal.io/nexus
Owning packages: service/history/queues · service/frontend · service/matching · common/nexus
In comparison reference Nexus Async Completion Callback The HTTP callback a handler invokes when an async Operation finishes; the server routes it to the caller's History. https://docs.temporal.io/nexus/operations
Owning packages: service/frontend · service/history/hsm/callbacks · chasm/lib/callback · common/callbacks
In comparison reference Nexus Operation Events Events in the caller's history recording Operation lifecycle (scheduled, started, completed, failed, cancelled, timed out). https://docs.temporal.io/nexus/execution-debugging
Restate: the Call command and its completion notifications in the journal.
Effect: the activity request and its reply.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Nexus Service Contract The shared code package, schema, or docs that let a caller use a Service. https://docs.temporal.io/nexus/services
No package ownership mapping recorded; use the reference sources below.
In comparison reference NexGen A code generator producing typed Nexus clients from a schema file. https://docs.temporal.io/nexus/nexgen
Restate / Effect: no analogue (types flow through TypeScript or Schema).
No package ownership mapping recorded; use the reference sources below.
In comparison reference Payload The wire representation of a value: bytes plus metadata (encoding, type). All inputs and outputs are Payloads. https://docs.temporal.io/dataconversion#payload
Owning packages: sdk · common/payload · common/payloads · common/codec · api/common/v1
In comparison reference Payload Converter Serializes a value to a Payload and back (JSON, protobuf, binary). https://docs.temporal.io/payload-converter
No package ownership mapping recorded; use the reference sources below.
In comparison reference Payload Codec Transforms Payloads to Payloads after serialization, typically for encryption or compression. Runs outside the workflow sandbox. https://docs.temporal.io/payload-codec
No package ownership mapping recorded; use the reference sources below.
In comparison reference Data Converter The bundle of Payload Converters, Payload Codecs, and Failure Converter an SDK uses. https://docs.temporal.io/dataconversion
Restate: Serde plus codec.
Effect: Schema per RPC.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Default Data Converter / Custom Data Converter The built-in chain (null, binary, protobuf JSON, protobuf binary, JSON) versus a user-supplied replacement. https://docs.temporal.io/default-custom-data-converters
Restate: serde.json default; custom Serde.
Effect: Schema is always explicit.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Codec Server / Remote data encoding An HTTP server exposing your Payload Codec so the Web UI and CLI can decode encrypted payloads. https://docs.temporal.io/codec-server
Restate / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Failure Temporal's typed error model carried in Events and across SDKs: ApplicationFailure, CancelledFailure, TimeoutFailure, TerminatedFailure, ServerFailure, ActivityFailure, ChildWorkflowFailure, NexusOperationFailure. https://docs.temporal.io/references/failures
Restate: TerminalError versus retryable errors, with a Failure{code, message, metadata} wire type. https://docs.restate.dev/develop/ts/error-handling
Effect: Effect Cause persisted through Workflow.Result schemas, plus typed error channels. E/workflow/Workflow.ts
Owning packages: common/failure · common/serviceerror · sdk · api/errordetails/v1
In comparison reference Failure Converter Converts language error objects to proto Failures and back. https://docs.temporal.io/failure-converter
No package ownership mapping recorded; use the reference sources below.
In comparison reference Visibility The subsystem and APIs for listing, counting, and searching executions. Written asynchronously to Elasticsearch or SQL, so it is eventually consistent. https://docs.temporal.io/temporal-service/visibility
Owning packages: common/persistence/visibility · common/persistence/visibility/manager · common/persistence/visibility/store · common/persistence/visibility/store/elasticsearch · common/persistence/visibility/store/sql · service/history/queues · api/visibilityservice/v1
In comparison reference List Filter The SQL-like query string accepted by list and count APIs. https://docs.temporal.io/list-filter
Owning packages: common/persistence/visibility/store/query · common/sqlquery
In comparison reference Search Attribute An indexed key usable in List Filters, set at start or upserted from workflow code. https://docs.temporal.io/search-attribute
Owning packages: common/searchattribute · common/searchattribute/sadefs · service/worker/addsearchattributes · service/frontend · cmd/tools/gensearchattributehelpers
In comparison reference Dual Visibility Running a secondary Visibility store during a migration. https://docs.temporal.io/dual-visibility
Restate / Effect: no analogue.
Owning packages: common/persistence/visibility/manager
In comparison reference Tag A key-value label on an emitted metric. https://docs.temporal.io/references/sdk-metrics
Owning packages: common/metrics · common/log/tag · api/metrics/v1
In comparison reference Temporal Web UI The UI for inspecting executions, histories, task queues, and schedules. https://docs.temporal.io/web-ui
No package ownership mapping recorded; use the reference sources below.
In comparison reference Temporal CLI / tctl The temporal command-line tool; tctl is its deprecated predecessor. https://docs.temporal.io/cli
Owning packages: cmd/tools/tdbg · api/cli/v1
In comparison reference Temporal SDK A language library providing the Client and the Worker, including the deterministic workflow runtime. https://docs.temporal.io/encyclopedia/architecture/temporal-sdks
Owning packages: sdk · common/sdk
In comparison reference Core SDK The shared Rust library (sdk-core) implementing polling, state machines, and replay for the TypeScript, Python, .NET, and Ruby SDKs via FFI. https://temporal.io/blog/why-rust-powers-core-sdk
No package ownership mapping recorded; use the reference sources below.
In comparison reference Temporal Client The SDK API to start, signal, query, update, describe, and list executions. https://docs.temporal.io/encyclopedia/temporal-client
No package ownership mapping recorded; use the reference sources below.
In comparison reference Multi-Cluster Replication Self-hosted asynchronous replication of executions from an active cluster to passive ones, with namespace-level failover. https://docs.temporal.io/self-hosted-guide/multi-cluster-replication
Restate / Effect: no analogue; durability is within one cluster.
Owning packages: service/history/replication · service/history/replication/eventhandler · service/history/ndc · service/history/api/replication · service/worker/replicator · common/cluster · api/replication/v1
In comparison reference Global Namespace A Namespace configured to replicate to a standby cluster. https://docs.temporal.io/global-namespace
Restate / Effect: no analogue.
Owning packages: common/namespace/nsreplication · service/worker/replicator · service/worker/migration · common/rpc/interceptor · service/history/shard
In comparison reference Failover / Failback Switching a Namespace's active cluster or region to the standby and back. https://docs.temporal.io/cloud/high-availability
No package ownership mapping recorded; use the reference sources below.
In comparison reference Replication Lag The delay between active and standby regions. https://docs.temporal.io/cloud/metrics/openmetrics/metrics-reference#temporal_cloud_v1_replication_lag_p99
Restate / Effect: no analogue.
Owning packages: service/history/replication
In comparison reference High Availability / High Availability features / Multi-region, Multi-cloud, Same-region Replication Cloud offerings that replicate a Namespace to a second region, cloud, or cell for failover. https://docs.temporal.io/cloud/high-availability
No package ownership mapping recorded; use the reference sources below.
In comparison reference Availability Zone Placement unit for Cloud HA. https://docs.temporal.io/cloud/high-availability
No package ownership mapping recorded; use the reference sources below.
In comparison reference Authorizer Plugin / Claim Mapper Self-hosted server plugins: the Claim Mapper extracts claims from a JWT, the Authorizer decides per API call. https://docs.temporal.io/self-hosted-guide/security
Owning packages: common/authorization · common/rpc/auth · common/rpc/encryption
In comparison reference Audit Logging Cloud feature recording forensic access information. https://docs.temporal.io/cloud/audit-logs
Restate / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Requests Per Second (RPS) Service-level rate limits configured via dynamic config. https://docs.temporal.io/references/dynamic-configuration#service-level-rps-limits
Owning packages: common/quotas · common/quotas/calculator · common/rpc/interceptor · service/frontend
In comparison reference Action / Actions Per Second (APS) Cloud's billing unit (roughly one per state transition that creates work) and its per-namespace rate limit. https://docs.temporal.io/cloud/pricing#action
Restate / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Temporal Cloud; Account ID; Namespace ID; Namespace Name; gRPC Endpoint The managed offering and its identifiers and per-namespace connection address. https://docs.temporal.io/cloud/namespaces
No package ownership mapping recorded; use the reference sources below.
In comparison reference General Availability / Public Preview / Pre-release Product release stages. https://docs.temporal.io/evaluate/product-release-stages
No package ownership mapping recorded; use the reference sources below.
In comparison reference Mutable state The materialized record of one execution (execution info, pending activities, timers, children, signals, versioning info), stored in the executions row and cached on the owning History host. Events are the log; mutable state is the fold over it. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
Owning packages: service/history/workflow · service/history/workflow/cache · service/history/interfaces · service/history/api/describemutablestate · api/persistence/v1
In comparison reference RangeID A monotonically increasing integer on each shard row. A History host claims a shard by compare-and-swapping it, and every write for that shard carries it; a mismatch means another host owns the shard and the write fails. Temporal's fencing token. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
Owning packages: service/history/shard · common/persistence · common/persistence/cassandra · common/persistence/sql
In comparison reference Shard controller Per-History-host component that watches cluster membership and acquires or releases the shards it should own. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
Owning packages: service/history/shard
In comparison reference Ringpop Gossip-based membership (SWIM) with a consistent hash ring, one ring per service, used to find which host owns a shard, task-queue partition, or registry. https://github.com/temporalio/ringpop-go
Owning packages: client · client/history · client/matching · client/frontend · client/admin · client/operator · common/resource
In comparison reference Transfer / timer / visibility / outbound / replication tasks The task categories History writes in the same transaction as mutable state. Transfer tasks are immediate (dispatch to Matching, start a child, deliver a signal); timer tasks fire at a time; visibility tasks update the index; outbound tasks make Nexus and callback HTTP calls; replication tasks feed XDC. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
Owning packages: service/history/tasks · service/history/queues · service/history/workflow
In comparison reference Queue processor The per-shard loop that reads one task category from its ack level, schedules tasks with priority and per-execution serialization, retries with backoff, and sends terminal failures to a dead-letter queue. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
Owning packages: service/history/queues · service/history/queues/common · common/tasks · service/history/api/listqueues · service/history/api/getdlqtasks
In comparison reference Ack level The checkpointed position in a task category below which every task is complete, persisted in shard info so a new owner resumes from there. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
Owning packages: service/history/queues · service/history/shard
In comparison reference Buffered events Events (signals, activity completions) that arrive while a Workflow Task is in flight. They are held and appended after the task completes so the worker's view stays consistent. https://github.com/temporalio/temporal/blob/main/docs/architecture/workflow-lifecycle.md
Owning packages: service/history/historybuilder · service/history/workflow
In comparison reference Speculative Workflow Task A Workflow Task that is never persisted, used by Update so that a rejected Update costs zero database writes. https://github.com/temporalio/temporal/blob/main/docs/architecture/speculative-workflow-task.md
Restate / Effect: no analogue.
Owning packages: service/history/workflow · service/history/queues
In comparison reference Transient Workflow Task A retried Workflow Task after a failure whose scheduled and started events are not written until it completes, so repeated failures do not bloat history. https://github.com/temporalio/temporal/blob/main/docs/architecture/workflow-lifecycle.md
Owning packages: service/history/workflow
In comparison reference Sticky queue A Task Queue private to one worker so Workflow Tasks for cached executions return to it. See Sticky Execution. https://docs.temporal.io/sticky-execution
No package ownership mapping recorded; use the reference sources below.
In comparison reference Sync match Matching handing a task directly to a parked long-poller without writing it to the backlog. https://github.com/temporalio/temporal/blob/main/docs/architecture/matching-service.md
Restate / Effect: no analogue.
Owning packages: service/matching
In comparison reference Backlog / spool Tasks persisted in the tasks table because no poller was waiting. https://github.com/temporalio/temporal/blob/main/docs/architecture/matching-service.md
Owning packages: service/matching · common/persistence · cmd/tools/fairsim
In comparison reference Task queue partition One of N physical sub-queues (default 4) of a Task Queue, arranged as a tree with forwarding to the root partition; the unit of Matching ownership. https://github.com/temporalio/temporal/blob/main/docs/architecture/matching-service.md
Restate / Effect: no analogue.
Owning packages: service/matching · client/matching · common/tqid
In comparison reference Worker Versioning / Worker Deployment / Build ID Mechanisms to route Workflow Tasks only to workers running compatible code. A Deployment Version is a named build; PINNED keeps an execution on its starting version, AUTO_UPGRADE moves it to the current one. https://docs.temporal.io/worker-versioning
Owning packages: service/matching · service/worker/workerdeployment · common/worker_versioning · service/worker/scanner/build_ids · api/deployment/v1
In comparison reference Patching (patched / deprecatePatch) SDK markers written to history so new code can branch on whether an old execution has already passed a change point. https://docs.temporal.io/patching
Owning packages: sdk · service/history/workflow
In comparison reference HSM (hierarchical state machines) The older framework for embedding typed state machines (callbacks, Nexus operations) inside mutable state. Being replaced by CHASM. https://github.com/temporalio/temporal/tree/main/service/history/hsm
Restate / Effect: no analogue.
Owning packages: service/history/hsm · service/history/hsm/callbacks · service/history/hsm/nexusoperations
In comparison reference CHASM (Coordinated Heterogeneous Application State Machines) A component-tree framework that lets non-workflow archetypes (standalone activities, schedules, callbacks) share the shard, routing, atomic-write, and replication substrate. https://github.com/temporalio/temporal/blob/main/docs/architecture/chasm.md
Owning packages: chasm · chasm/lib/workflow · chasm/lib/all · service/history · cmd/tools/protoc-gen-go-chasm · api/chasm/v1
In comparison reference Versioned transition A (failover version, transition count) pair acting as the logical clock for mutable state and CHASM, used by replication and conflict resolution. https://github.com/temporalio/temporal/blob/main/docs/architecture/chasm.md
Owning packages: common/persistence/transitionhistory · chasm · service/history/workflow
In comparison reference Failover version / version history Per-event version numbers tied to the active cluster so XDC can detect and resolve conflicting branches. https://docs.temporal.io/self-hosted-guide/multi-cluster-replication
Restate / Effect: no analogue.
Owning packages: common/persistence/versionhistory · common/cluster · service/history/ndc
In comparison reference History branch / tree An execution's events can fork on reset or conflict resolution; history_tree tracks branches and history_node stores event batches per branch. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
Restate / Effect: no analogue.
Owning packages: common/persistence · common/persistence/versionhistory · service/history/ndc
In comparison reference Dynamic config Typed, hot-reloadable settings keyed by namespace, task queue, or shard, read from YAML. https://docs.temporal.io/references/dynamic-configuration
Owning packages: common/dynamicconfig · cmd/tools/gendynamicconfig
In comparison reference System workflows Temporal workflows the Worker service runs against the server itself (scanner, batcher, schedules V1, worker deployments, migrations). https://docs.temporal.io/temporal-service/temporal-server#worker-service
Owning packages: service/worker/scanner · service/worker/batcher · service/worker/deletenamespace · service/worker/parentclosepolicy · service/worker/addsearchattributes · common/sdk
In comparison reference Message protocol (Update) The worker-to-server protocol for Update requests, acceptance, and completion carried alongside Workflow Tasks. https://github.com/temporalio/temporal/blob/main/docs/architecture/message-protocol.md
Owning packages: common/protocol · service/history/workflow/update
In comparison reference Bifrost Restate's replicated, segmented log abstraction. Each partition has one log, and that log is the write-ahead log for every state change in the partition. https://docs.restate.dev/references/architecture
Temporal: no analogue; the database transaction log plays this role implicitly.
Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Loglet One segment of a Bifrost log with a fixed provider (in-memory, local RocksDB, or replicated). A log is a chain of loglets. https://docs.restate.dev/server/clusters
Temporal / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Sealing / chain extension Making the current loglet read-only and appending a new loglet to the chain, used to reconfigure (new nodeset, new sequencer) or recover. Consensus is needed only on the metadata-store compare-and-swap that extends the chain. https://github.com/restatedev/restate/blob/main/crates/bifrost/src/bifrost_admin.rs
Temporal / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Sequencer The single node ordering appends for a replicated loglet and replicating them to a write quorum of log-servers. https://docs.restate.dev/server/clusters
Temporal / Effect: no analogue.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Nodeset / replication property The log-server nodes a loglet writes to and how many must acknowledge. https://docs.restate.dev/server/clusters
No package ownership mapping recorded; use the reference sources below.
In comparison reference Log-server The node role that stores replicated loglet records in RocksDB. https://docs.restate.dev/server/overview
No package ownership mapping recorded; use the reference sources below.
In comparison reference Metadata store A Raft-replicated (or etcd, S3, DynamoDB backed) versioned key-value store holding nodes config, partition table, log chains, schema registry, and per-partition epochs. https://docs.restate.dev/server/metadata
No package ownership mapping recorded; use the reference sources below.
In comparison reference Partition / partition processor A key range of the 64-bit partition key space and the state machine that applies that partition's log into RocksDB. https://docs.restate.dev/server/clusters
No package ownership mapping recorded; use the reference sources below.
In comparison reference Partition leader / leader epoch The replica allowed to produce side effects. It claims a new epoch through the metadata store and announces itself by appending to the log; records from stale epochs are applied and ignored. https://docs.restate.dev/server/clusters
Temporal: RangeID. See B.1.
Effect: shard lease. E/cluster/RunnerStorage.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Partition store Per-partition RocksDB with tables for invocation status, journal, key-value state, timers, inbox and outbox, promises, locks, deduplication, and FSM metadata. https://github.com/restatedev/restate/blob/main/crates/partition-store/src/keys.rs
No package ownership mapping recorded; use the reference sources below.
In comparison reference Invocation One durable execution of a handler, identified by an InvocationId, with a status lifecycle (scheduled, inboxed, invoked, suspended, paused, completed). https://docs.restate.dev/foundations/invocations
No package ownership mapping recorded; use the reference sources below.
In comparison reference Journal The invocation's ordered command and notification entries, stored in the partition store and replayed to the SDK on every attempt. https://docs.restate.dev/foundations/key-concepts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Invoker The leader-side component that drives invocations against endpoints over HTTP/2, replays the journal, forwards new commands to the state machine, and retries on failure. https://docs.restate.dev/references/architecture
No package ownership mapping recorded; use the reference sources below.
In comparison reference Service protocol The versioned wire protocol (V1 to V7) between invoker and SDK: start message, commands, notifications, suspension, run completion proposals, acks. https://github.com/restatedev/restate/blob/main/service-protocol/dev/restate/service/protocol.proto
No package ownership mapping recorded; use the reference sources below.
In comparison reference Deployment An immutable registered endpoint (URL or Lambda ARN) discovered via /discover. Invocations pin to the deployment they started on. https://docs.restate.dev/services/versioning
No package ownership mapping recorded; use the reference sources below.
In comparison reference Schema registry The metadata-store record of services, handlers, and deployments, also appended to each partition log so replicas agree on schema at the same point. https://docs.restate.dev/server/metadata
No package ownership mapping recorded; use the reference sources below.
In comparison reference Service / Virtual Object / Workflow (Restate) The three service kinds. Services are unkeyed and concurrent. Virtual Objects are keyed with K/V state and exclusive single-writer handlers plus shared read handlers. Workflows are keyed, single-run objects with a run handler, shared handlers, and durable promises. https://docs.restate.dev/foundations/services
Temporal: Activity or stateless workflow; entity workflow; workflow with Update and Query handlers. https://docs.temporal.io/workflows
Effect: entity RPC; entity; Workflow. E/cluster/Entity.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Exclusive / shared handler On a Virtual Object or Workflow, exclusive handlers serialize per key; shared handlers run concurrently and may read state and promises. https://docs.restate.dev/foundations/handlers
No package ownership mapping recorded; use the reference sources below.
In comparison reference Virtual queue (vqueue) Per-key or per-service admission queue with a lock and deficit-round-robin scheduling, on by default in v1.8; replaces the older inbox. https://docs.restate.dev/services/flow-control
No package ownership mapping recorded; use the reference sources below.
In comparison reference Inbox / outbox / shuffle The inbox holds queued invocations for a locked key (legacy). The outbox holds cross-partition messages. The shuffle is the leader task that delivers outbox messages to other partitions. https://docs.restate.dev/references/architecture
Temporal: transfer tasks. See B.1.
Effect: persisted messages plus Notify. E/cluster/Sharding.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Awakeable An ID handed to an external system that, when resolved or rejected, delivers a completion into the invocation's journal. https://docs.restate.dev/develop/ts/external-events
No package ownership mapping recorded; use the reference sources below.
In comparison reference Durable promise A named promise on a Workflow that any handler of that workflow key can resolve, reject, peek, or await. https://docs.restate.dev/develop/ts/external-events
No package ownership mapping recorded; use the reference sources below.
In comparison reference Idempotency key (Restate) A request header that makes the invocation ID deterministic so retries attach to the same invocation and get its stored result. https://docs.restate.dev/services/invocation/http
No package ownership mapping recorded; use the reference sources below.
In comparison reference Snapshot / trim Periodic upload of a partition's RocksDB to object store, and truncation of the log below the durable LSN. https://docs.restate.dev/server/snapshots
No package ownership mapping recorded; use the reference sources below.
In comparison reference Cluster controller The admin-role component that places partition replica sets, picks leaders, seals and extends log chains, and triggers snapshots. https://docs.restate.dev/server/clusters
Temporal: shard controller plus Ringpop; no single controller. See B.1.
Effect: none; placement is a pure function of the runner table. E/cluster/Sharding.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference restate-lite An embeddable single-process server with a local loglet and one partition, used by restate dev. https://github.com/restatedev/restate/tree/main/lite
No package ownership mapping recorded; use the reference sources below.
In comparison reference Runner A process that registers in cluster_runners, owns shards, hosts entities, and serves the runner RPCs (Ping, Notify, Effect, Stream, Envelope). E/cluster/Runner.ts, E/cluster/Runners.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Shard / shard group One of 300 hash buckets per group; an entity's shard is hash(entityId) % 300 + 1. Groups restrict entity types to subsets of runners. E/cluster/ShardId.ts, E/cluster/ShardingConfig.ts
Temporal: History Shard. Restate: partition.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Hash ring assignment Every runner computes shard placement locally from the runner table with a weighted consistent hash ring; there is no central shard manager in this snapshot. E/cluster/Sharding.ts
Temporal: Ringpop ring. Restate: cluster controller scheduler.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Runner storage / shard lock acquire, refresh, release on a shard, implemented as Postgres or MySQL advisory locks, or a cluster_locks row with 35-second expiry. A lease, not a fencing token. E/cluster/RunnerStorage.ts, E/cluster/SqlRunnerStorage.ts
Temporal: RangeID (fenced). Restate: leader epoch (fenced).
No package ownership mapping recorded; use the reference sources below.
In comparison reference Entity The actor primitive: a type plus an ID with an RPC group as its interface, one RPC server per resident ID, serialized by default, reaped after idle time. E/cluster/Entity.ts
Temporal: entity workflow or CHASM component. Restate: Virtual Object.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Entity address / envelope (entityType, entityId, shardId) plus the wrapped request, interrupt, or ack-chunk message. E/cluster/EntityAddress.ts, E/cluster/Envelope.ts
Temporal: (namespace, workflowId, runId) plus a history task. Restate: (partition key, invocation id) plus a log envelope.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Message storage The cluster_messages and cluster_replies tables (or an in-memory driver). Persisted requests deduplicate on entityType/entityId/tag/primaryKey; replies are unique per (request_id, kind). E/cluster/MessageStorage.ts, E/cluster/SqlMessageStorage.ts
Temporal: task tables plus history. Restate: log plus partition store.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Persisted vs volatile A per-RPC annotation. Persisted requests go through storage (at-least-once); volatile ones go straight over the wire (at-most-once). E/cluster/ClusterSchema.ts
Temporal: everything is persisted. Restate: everything through ingress is persisted.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Uninterruptible / WithTransaction / ShardGroup / DeliverAt RPC annotations controlling interrupt handling, running the handler inside the storage transaction, placement, and delayed delivery. E/cluster/ClusterSchema.ts, E/cluster/DeliverAt.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Storage poll The owner's loop claiming unprocessed messages for its shards (UPDATE ... FOR UPDATE), with last_read reclaim after 10 minutes and deliver_at filtering. E/cluster/SqlMessageStorage.ts
Temporal: queue processors reading from the ack level. Restate: log read stream.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Notify Best-effort RPC telling an owner that a persisted message was written so it polls sooner. E/cluster/Runners.ts
Temporal: the in-memory notify channel feeding immediate queues. Restate: ingestion session to the leader.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Snowflake A 64-bit time-ordered ID with a machine ID handed out by the runner table. E/cluster/Snowflake.ts
Temporal: task IDs minted from the RangeID. Restate: ULID-based invocation IDs.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Singleton An effect that runs on whichever runner owns the shard for its name. E/cluster/Singleton.ts
Temporal: a system workflow with a fixed Workflow ID. Restate: a Virtual Object with a fixed key.
No package ownership mapping recorded; use the reference sources below.
In comparison reference ClusterCron Cron built from a singleton seed plus a self-rescheduling persisted run message. E/cluster/ClusterCron.ts
Temporal: Schedule. Restate: delayed self-send.
No package ownership mapping recorded; use the reference sources below.
In comparison reference WorkflowEngine The interface (register, execute, poll, interrupt, resume, activityExecute, deferredResult, deferredDone, scheduleClock) with an in-memory implementation and the cluster implementation. E/workflow/WorkflowEngine.ts
Temporal: the Workflow Service API plus sdk-core. Restate: the service protocol.
No package ownership mapping recorded; use the reference sources below.
In comparison reference ClusterWorkflowEngine Implements a workflow as entity type Workflow/<tag> with four persisted RPCs: run, activity, deferred, resume. E/cluster/ClusterWorkflowEngine.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference WorkflowInstance Per-run in-memory state (execution ID, scope, suspended, interrupted, abandoned, awaited and completed deferreds, activity state), rebuilt on every replay. E/workflow/WorkflowEngine.ts
Temporal: the worker's cached workflow plus server mutable state. Restate: the SDK VM state plus invocation status.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Execution ID sha256("<tag.length>:<tag>:<idempotencyKey(payload)>") truncated to 16 bytes; identical payloads always map to the same execution. E/workflow/Workflow.ts
Temporal: Workflow ID. Restate: invocation ID from idempotency key.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Activity (Effect) A named durable step whose result is memoized as the reply to the activity{name, attempt} request; runs on the owner runner. E/workflow/Activity.ts
Temporal: Local Activity. Restate: ctx.run.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Attempt A counter bumped by Activity.retry, part of the dedup key so each retry is its own durable request. E/workflow/Activity.ts
Temporal: activity attempt number. Restate: retry count in StartMessage.
No package ownership mapping recorded; use the reference sources below.
In comparison reference DurableDeferred A named external completion slot. Awaiting it suspends the workflow; completing it by token wakes it. E/workflow/DurableDeferred.ts
Temporal: Signal or async activity completion. Restate: awakeable or durable promise.
No package ownership mapping recorded; use the reference sources below.
In comparison reference DurableClock A sleep that is in-process under 60 seconds and a deliver_at message above it. E/workflow/DurableClock.ts
Temporal: Timer. Restate: ctx.sleep.
No package ownership mapping recorded; use the reference sources below.
In comparison reference DurableQueue A persisted queue plus a deferred, for handing work to external consumers at-least-once. E/workflow/DurableQueue.ts
Temporal: a Task Queue consumed by activity workers. Restate: Kafka subscription or one-way sends.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Suspend / Suspended result The workflow self-interrupts, a Suspended reply is stored, and the run message is marked processed until something resets it. E/workflow/Workflow.ts
Temporal: a workflow blocked with no in-flight task. Restate: SuspensionMessage and status Suspended.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Reset (clearReplies) Deleting the run's exit reply and clearing processed and last_read so the storage poll redelivers the original run and the body replays. E/cluster/SqlMessageStorage.ts
Temporal: scheduling a new Workflow Task. Restate: re-invoke after a notification.
No package ownership mapping recorded; use the reference sources below.
In comparison reference SuspendOnFailure / CaptureDefects References controlling whether failures become suspensions for manual resume, and whether defects are stored as results. E/workflow/Workflow.ts
Temporal: Workflow Task failure retries forever by default, which is the closest "pause until fixed". Restate: PauseError and onMaxAttempts: pause.
No package ownership mapping recorded; use the reference sources below.
In comparison reference Compensation withCompensation registers finalizers on the workflow scope that run only if the final exit is a failure; rebuilt on replay. E/workflow/Workflow.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Abandon Marking an instance as no longer owned (shard lost) so it skips parent resume and durable finalizers. E/cluster/internal/clusterAbandon.ts
Temporal: shard ownership lost error. Restate: leader step-down.
No package ownership mapping recorded; use the reference sources below.
In comparison reference WorkflowProxy Generated RPC and HTTP groups (execute, discard, resume) exposing workflows to external callers. E/workflow/WorkflowProxy.ts
Temporal: Frontend plus Temporal Client. Restate: ingress.
No package ownership mapping recorded; use the reference sources below.
In comparison reference layerMemory / TestRunner / SingleRunner The in-process engine, the all-in-memory cluster, and the one-process-plus-SQL cluster for tests and small deployments. E/workflow/WorkflowEngine.ts, E/cluster/TestRunner.ts, E/cluster/SingleRunner.ts
No package ownership mapping recorded; use the reference sources below.
In comparison reference Journal and replay The technique all three use: record the results of non-deterministic steps, re-run the code, and substitute recorded results so the code reaches the same point without redoing side effects. https://docs.temporal.io/temporal#durable-execution
No package ownership mapping recorded; use the reference sources below.
In comparison reference Determinism The requirement that workflow code issues the same durable steps in the same order on every replay. Enforced by Temporal, detected by Restate, assumed by Effect. https://docs.temporal.io/workflow-definition#deterministic-constraints
No package ownership mapping recorded; use the reference sources below.
In comparison reference Fencing token A monotonically increasing value a writer must present so a stale owner's writes are rejected. Temporal's RangeID and Restate's leader epoch are fencing tokens; Effect's lease is not. https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
No package ownership mapping recorded; use the reference sources below.
In comparison reference Transactional outbox Writing the intent to perform a side effect in the same transaction as the state change, then having a separate consumer perform it. Temporal's task rows, Restate's actions-from-log, and Effect's persisted messages are all instances. https://microservices.io/patterns/data/transactional-outbox.html
No package ownership mapping recorded; use the reference sources below.
In comparison reference At-least-once / at-most-once / exactly-once Delivery guarantees. All three deliver durable steps at least once; only side effects inside the same database transaction (Effect's WithTransaction) are exactly-once. https://docs.temporal.io/activity-definition#idempotency
No package ownership mapping recorded; use the reference sources below.
In comparison reference Push vs pull dispatch Whether the engine calls user code (Restate; Temporal for Nexus and callbacks) or user code polls the engine (Temporal workers). Effect runs both in one process. https://docs.temporal.io/task-queue
No package ownership mapping recorded; use the reference sources below.
In comparison reference Single-writer At most one in-flight mutation per key or execution. Temporal: one Workflow Task at a time. Restate: exclusive handlers via the vqueue lock. Effect: entity concurrency. https://docs.restate.dev/foundations/handlers
No package ownership mapping recorded; use the reference sources below.
In comparison reference Log-first vs database-first Whether the authoritative record is an ordered replicated log (Restate, fireline, firegrid) or rows in a database with conditional writes (Temporal, Effect). https://docs.restate.dev/references/architecture
No package ownership mapping recorded; use the reference sources below.
In comparison reference