Temporal compatibility
This page lists the Temporal features that work on Catalyst, the ones that aren't available yet, and the places where your application can see Catalyst behave differently from a Temporal server. To connect an application, see Temporal workflows on Catalyst.
Temporal workflows on Catalyst are in preview, so these lists can change.
Need a feature that isn't here, or the best performance?
Workflows written with the Dapr Workflow SDKs run natively on Catalyst, with every Catalyst workflow feature. If you need something this page lists as not available, or you want the best performance, migrate your workflows to the Dapr Workflow SDKs.
SDKs and tools
| SDK or tool | Status |
|---|---|
| Go, Java, Python and TypeScript SDKs | Tested against Catalyst |
| .NET, Ruby and PHP SDKs | Not tested yet. They use the same API, so they're expected to work |
| Temporal CLI | Tested against Catalyst. The commands that work are listed below |
| Temporal Web UI | Not available. Use the Catalyst console |
Supported features
| Area | What works |
|---|---|
| Workflow code | Deterministic replay with the SDK's own checks; timers and timer cancellation; waiting on conditions; SideEffect and MutableSideEffect; local activities; selectors, channels and coroutines; sticky worker caching |
| Versioning | GetVersion, patched and deprecatePatch; replaying histories exported from Catalyst with the SDK's workflow replayer |
| Starting workflows | Workflow ID reuse and conflict policies; run and execution timeouts; start delay; workflow retry policies; cron workflows; memo, headers and context propagation; eager start |
| Activities | Any task queue in the namespace; retry policies with backoff and non-retryable errors; start-to-close, schedule-to-close, schedule-to-start and heartbeat timeouts; heartbeats with details; completing an activity later, by task token or by ID; task queue rate limits |
| Cancellation | Cancelling workflows and activities, with TRY_CANCEL, WAIT_CANCELLATION_COMPLETED and ABANDON |
| Child workflows | Child workflows with parent close policies; continue-as-new |
| Messages | Signals and signal-with-start; queries, including the stack trace query; updates with validators, update-with-start and polling an update by its ID |
| Schedules | Create, describe, update, pause, unpause, trigger, backfill, list and delete; calendars, intervals, cron strings, time zones and jitter; every overlap policy and catch-up windows |
| Listing workflows | List and count with AND, OR, NOT and parentheses; custom search attributes, including registering new ones |
| Operations | Pause and unpause; terminate, cancel, signal and delete, one workflow at a time or in a batch by query; listing workers, for SDKs that send worker heartbeats (Go SDK 1.49 or later, and the Java, Python and TypeScript SDKs) |
| Client features | Interceptors; data converters; payload codecs, including encryption; the SDK test frameworks |
| Temporal CLI | temporal workflow: start, execute, list, count, describe, show, trace, stack, signal, query, cancel, terminate, pause, unpause and delete; temporal schedule; temporal batch; temporal task-queue describe and config; temporal worker list and describe; temporal operator search-attribute |
| Catalyst | Workflow list and history in the console and with diagrid workflow; Dapr apps in the project can start, signal, suspend, resume and terminate the same workflows; plan limits, archiving and retention |
Not available yet
| Feature | What to do instead |
|---|---|
Reset, with temporal workflow reset or an SDK client | Rerun the workflow from the Catalyst console or the Diagrid CLI. See Rerun a workflow instead of resetting it |
| Worker versioning, deployments and build IDs | Use GetVersion or patching. A worker that turns on worker versioning gets PermissionDenied |
| Nexus | |
| Standalone activities, activity pause and activity options | |
| Signals, cancellations and child workflows across namespaces | Keep workflows that talk to each other in one App |
| Creating or changing namespaces with Temporal's APIs | Create, change and delete Apps in Catalyst. Registering any other namespace returns PermissionDenied |
| Client mTLS certificates | Coming soon. Until then, use the App's API token |
| Temporal Web UI | Use the Catalyst console and the Temporal CLI |
| Temporal's archival APIs | Catalyst's archiving and retention apply instead |
| Temporal's multi-cluster replication | Catalyst has its own multi-region support: a project in a region group runs in several regions behind one endpoint, with failover between them. See multi-region high availability |
| Moving running workflows from another Temporal cluster | Start new workflows on Catalyst and let running ones finish where they are |
| Go worker sessions | Not tested yet |
Rerun a workflow instead of resetting it
Temporal's reset isn't available on Catalyst: temporal workflow reset and the SDKs' ResetWorkflowExecution return Unimplemented. To run a closed workflow again from an earlier point, rerun it from the Catalyst console or with the Diagrid CLI.
A rerun starts a new workflow, under a workflow ID you choose. Its history is the original workflow's history up to the event you pick. Catalyst runs that step again, and your workers carry on from there. The new workflow is an ordinary Temporal workflow, so temporal workflow describe and show read it and your clients can wait for its result.
You can rerun from:
- An activity. You can give it a new input.
- A timer the workflow code started. The console shows it as
Timerfollowed by the timer ID. - A child workflow. You can give it a new input. The child starts again under a new workflow ID.
- A signal or cancellation the workflow sent to another workflow.
A new input replaces the arguments of the activity or child workflow with one JSON value, so it suits an activity or child workflow that takes a single argument.
Before you rerun:
- Make sure the original workflow is completed, failed or terminated. Terminate a running workflow first.
- Deploy any fixed workflow code. The new workflow replays the original's history up to the event, so the code before that event must stay deterministic. Use
GetVersionor patching for changes there, as you would before a reset.
In the console
- Open the workflow execution in the workflows view.
- Choose Rerun from event in its action menu. You can also select a step in the execution graph and choose Rerun from this event.
- Select the event, enter the workflow ID for the new workflow and, if you want, a new input.
With the Diagrid CLI
diagrid workflow get lists the workflow's history, with each event's eventId:
diagrid workflow get order-1234 --id orders
Rerun the workflow from the event you picked:
diagrid workflow rerun --id orders --instance-id order-1234 --event-id 12 --new-workflow-id order-1234-rerun
Add --input with a JSON value to give the activity or child workflow a new input. See diagrid workflow rerun for every option.
How a rerun differs from a reset
| Reset on a Temporal server | Rerun on Catalyst |
|---|---|
| Keeps the workflow ID and starts a new run of it | Starts a new workflow, under the workflow ID you choose |
| Restarts from a workflow task, so the workflow code makes that task's decisions again | Restarts from an activity, timer, child workflow or sent signal, and runs that step again |
| Works on running workflows, and terminates them | Works on completed, failed and terminated workflows |
| Works on child workflows | Doesn't work on a child workflow. Rerun its root parent workflow from the step that started the child |
| Uses the event IDs in the Temporal history | Uses the event IDs in the console and in diagrid workflow get, which differ from the ones temporal workflow show prints |
| Sends again the signals received after the reset point | Doesn't send the signals received after the event |
Differences from a Temporal server
Most applications don't notice these. Check them if your workflows depend on the behavior.
| Area | What you see on Catalyst |
|---|---|
| History size | A workflow's history can grow to just under the App's maximum request size, 16 MiB by default, where Temporal allows 50 MB. A workflow that reaches the limit is terminated with "Workflow history size exceeds limit.", and a signal or update that would pass it is refused. The SDK suggests continuing as new at 2 MiB of history or 4,096 events. Workflows with large payloads should continue as new sooner |
| Payload size | Payloads up to 2 MiB, as on Temporal, at the default maximum request size. A smaller maximum request size lowers it |
| Earlier runs | Catalyst keeps only the latest run of each workflow ID. Reusing the ID of a closed workflow, or continuing as new, replaces the previous run's history, so you can't replay an earlier run. This also applies to each run of a cron workflow |
| Terminate | Terminating a workflow also terminates its child workflows, whatever their parent close policy says, including ABANDON |
| Child workflow IDs | If a child's workflow ID is already in use, the parent sees the child start and then fail, instead of getting a start failure |
| Search attributes | A workflow can set a search attribute that isn't registered. Temporal fails the workflow task instead |
| List results | A new or changed workflow takes about a second to show in list and count results |
| Busy Apps | When an App has more work in flight than it can take on, starting new workflows fails with ResourceExhausted, which the SDKs retry with backoff. Running workflows, signals, queries and updates carry on |
| Waiting activities | An App can hold up to 10,000 activity attempts waiting for workers at once. Keep workers running so attempts don't build up |
| Workers | A namespace lists up to 2,000 workers. A worker is listed once it sends its first worker heartbeat. Older SDKs, such as Go SDK versions before 1.49, don't send them, so their workers poll and run normally but aren't listed |
| Namespace retention | temporal operator namespace describe shows a retention of 0s when the App keeps closed workflows until they're purged. A Temporal server always reports at least a day |
| Batch operations | A batch job acts on at most 10,000 workflows. Run a terminate, cancel or delete job again to act on the rest |
| Task queue rate limits | Enforced, but a queue that was quiet can briefly hand out a few more tasks than its limit, and a change can take up to 10 seconds to apply everywhere |
| Priority and fairness | Priority and fairness keys are accepted but have no effect yet. Support is coming soon |
| Schedules | Jittered start times differ from Temporal's, within the same bounds |
| Summaries | Timer summaries, such as the ones the Go SDK adds for workflow.Sleep, are often not recorded |
