Client owner and public API for workflow operations.
A client owns the backend connection resources. Workflow operations resolve a current backend handle from the client process and then call the backend directly; the client process is not a request proxy.
Summary
Functions
Returns a specification to start this module under a supervisor.
Fetches a workflow's history, parsed.
Starts a workflow.
Functions
Returns a specification to start this module under a supervisor.
See Supervisor.
Fetches a workflow's history, parsed.
Returns {:ok, %Temporalex.History{}} — every event with its id, server
timestamp, kind (:workflow_execution_started, :activity_task_scheduled,
:workflow_task_failed, …) and attributes. Temporalex.History.stuck_reason/1
reads the latest failed workflow task's failure out of it — the SDK-native
answer to "why is this workflow stuck".
Pass raw: true for the undecoded temporal.api.history.v1.History
protobuf instead — the format to write to disk as a replay fixture.
Starts a workflow.
Beyond the usual :workflow_id, :task_queue, timeouts, :retry_policy,
:search_attributes, and :cron_schedule, this accepts:
:priority— task priority and fairness, as a keyword list::priority_key— positive integer, smaller is higher priority. The server's maximum is configurable and defaults to 5; an unset key gets the server default (the midpoint, 3 by default).:fairness_key— short string, max 64 bytes, typically a tenant id. Tasks sharing a key are dispatched in proportion to their weight, so a single noisy tenant cannot monopolise a task queue.:fairness_weight— float, clamped server-side to[0.001, 1000], default1.0.
Each priority field is optional, and an unset field inherits from the calling
workflow or falls back to the server default. Omit :priority entirely for
the previous behaviour.
Temporalex.Client.start_workflow(client, Checkout, order,
workflow_id: "checkout-#{order_id}",
priority: [priority_key: 2, fairness_key: salon_id]
)Server support
Priority needs a server that supports it, and an older one accepts the
field and silently drops it rather than complaining. Measured: 1.29.7
and 1.31.2 record all three fields; 1.27.4 reports priority: null
in both describe and history, including for workflows started by the
temporal CLI itself. Check yours before designing around this:
temporal operator cluster describe -o json | grep serverVersionAnd recording is not the same as honouring. We have confirmed 1.31.2 records priority; we have not been able to demonstrate that it changes dispatch order. Treat priority as advisory until you have measured it on your own server with your own workload — do not build a tenant fairness guarantee on it untested.