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 (rerunning a workflow from an earlier point) | Start a new workflow |
| 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 |
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 |
