Client and Worker Capabilities

Choose a surface for what the process needs to do. The dw CLI and the first-party PHP, Python, and Rust SDKs share the v2 control-plane and worker contracts, but their operator, client, and worker roles are not identical.

This all-client guide remains at the original /docs/2.0/polyglot/cli-python-parity/ route so existing links keep working.

Capability comparison

Capability	dw CLI	PHP SDK	Python SDK	Rust SDK
Workflow lifecycle	Supported: start, list, inspect, wait, cancel, terminate, and archive operator commands. Commands	Supported: start, describe, list, await results, cancel, and terminate through Client and WorkflowHandle. Lifecycle evidence	Supported: start, list/describe, await results, cancel, and terminate through the async client. Workflow operations	Supported: start, describe, await results, cancel, and terminate through Client and WorkflowHandle. Terminal operations
Signals	Supported: send by workflow ID or selected run. Commands	Supported: client and handle send methods plus worker signal history. PHP API	Supported: async client sends and workflow workers handle signals. Messages	Supported: client and handle sends plus worker signal handling. Rust API
Queries	Supported: execute a named read-only query with structured output. Commands	Supported: client and handle queries plus registered worker query handlers. PHP API	Supported: async client queries plus replayed worker query handlers. Messages	Supported: client queries and replayed worker query handlers when runtime discovery advertises query-task support. Rust API
Updates	Supported: submit and wait for accepted or completed outcomes. Commands	Supported: updateWorkflow and registerUpdate; the PHP SDK does not expose validator authoring and declares no validators. PHP API	Supported: clients, workflow handlers, and synchronous declared validators when discovery advertises the pre-accept contract. Validator-bearing workers refuse unsupported runtimes. Messages	Supported: client, handle, JSON/Avro, and registered worker update surfaces; the Rust SDK does not expose validator authoring and declares no validators. Updates
Schedules	Supported: complete schedule lifecycle, backfill, and audit history. Commands	Supported: complete schedule lifecycle and listing through Client. PHP API	Supported: complete async schedule lifecycle and audit-history paging. Schedules	Not supported: the current Rust SDK does not claim a schedule-management API. Use CLI, PHP, Python, or the server API.
Visibility	Supported: workflow/run search, workers, task queues, history, and diagnostic JSON. Commands	Supported: workflow filtering/pagination, history, namespaces, workers, and task queues. Visibility evidence	Supported: workflow, schedule, namespace, worker, queue, history, and search-attribute client surfaces. Client API	Different: selected-run describe/result is supported; fleet-wide list/search and namespace administration are not claimed. Rust client
Worker execution	Intentionally different: low-level worker-protocol commands support diagnostics and conformance; dw is not an application worker runtime. Worker commands	Supported: remote workflow, activity, query, and update handlers through durable-workflow/sdk. PHP worker	Supported: deterministic workflow and activity workers. Python worker	Supported: native workflow, activity, query, and update handlers. Rust worker API

Supported means the named current release surface exposes the capability. Different identifies an intentional scope boundary. Not supported is an explicit current gap, not a hidden promise. Runtime protocol discovery remains authoritative when a capability depends on a negotiated worker protocol.

Evidence by product surface

CLI

The CLI overview defines installation, profiles, structured output, and exit behavior. The command reference is the complete operator surface, including lifecycle, messages, schedules, visibility, and the low-level worker-protocol commands that are intentionally not an SDK worker loop.

PHP SDK

The pinned PHP SDK exposes framework-neutral client and remote-worker APIs. Its current public surface includes workflow lifecycle and result handles, signals, queries, updates, schedules, workflow filtering/history, namespace, worker, and task-queue visibility, plus registered workflow, activity, query, and update handlers. See the PHP SDK guide and generated PHP API reference.

Python SDK

The Python SDK combines an async control-plane client with deterministic workflow and activity workers. Its guide publishes client operations, message handlers, worker execution, and schedule management. The generated Python API reference carries exact signatures and result types.

Rust SDK

The published Rust SDK exposes control-plane and selected-run lifecycle, signals, replayed queries, updates, and native workflow/activity workers. Update support includes Client::update_workflow, WorkflowHandle::update, Worker::register_update, and their Avro-value variants. Schedule management and fleet-wide list/search remain explicit gaps. See the Rust SDK guide and generated Rust API reference.

Shared contract evidence

All four products target the same versioned HTTP+JSON control plane and public payload envelope. Evidence is split by what it proves:

• the Capability Index records exact artifact floors and current breadth;
• the Platform Conformance Suite records cross-client and cross-worker runtime scenarios;
• CLI and Python repositories retain shared request fixtures for operations whose semantic request bodies are byte-for-byte compared today;
• PHP and Rust public API references and release tests establish the additional supported methods listed above.

The existence of a shared fixture in two repositories does not imply that other SDKs lack the operation. Conversely, a common endpoint does not imply that every product exposes the same operator or worker role.

Adding or extending a client surface

When adding a new CLI or SDK operation:

1. Keep paths, methods, semantic fields, payload envelopes, and error outcomes language-neutral.
2. Add request and runtime evidence for every participating client or worker.
3. Document deliberately different syntax or role boundaries.
4. Mark unsupported products explicitly.
5. Treat language-specific serialization, file paths, class names, or error shapes as bugs in the public contract.