Repository navigation
Document separate workflow and activity worker processes #161
Description
Workflows that coordinate small durable steps and activities that perform heavy CPU or I/O work often need different process resources and scaling. Python supports separate handler sets, but the public guide currently presents a combined worker without a complete runnable process-split recipe.
Validated at Python main 101c591f45de3e0b03dc9d87b64a1254ddfe10e5:
- Worker.run starts workflow and activity poll loops only for the corresponding registered handlers. This capability already exists.
- Task-family integration controls contain split/mixed/timer cases for
runandrun_until. They were read, not rerun for this documentation finding. - Current shared Python guide documents handler lists and concurrency; admission covers queue budgets. Neither gives a complete operational recipe for this split.
P2 documentation/example task. This is separate from delivered #119, which corrected polling for empty handler sets. No current deadlock, memory leak, eager-dispatch defect or performance gain is asserted.
Acceptance:
- Add a runnable example on the Python SDK site with separate workflow-only and activity-only processes, distinct worker IDs, a named supported published Server/SDK baseline, and clear start/stop commands.
- Demonstrate successful remote activity dispatch and completion with honest registration, supported-type and queue/routing observations. A shared queue with type filters is not the same as configuring a distinct activity queue; only show queue-routing APIs the SDK supports.
- Explain independent workflow/activity slot and process-resource tuning, async blocking risks and downstream budgets. Do not advise setting an unsupported zero concurrency value.
- Explain the boundary with opted-in local activities, sessions and sticky history caches. Process separation does not make local resources durable, eliminate application contention or automatically redistribute every in-flight task.
- Qualify both processes, an activity retry and graceful shutdown through the normal installed artifacts. Link from the shared worker/admission guide rather than placing service code in embedded Laravel examples.
Activity
rmcdaniel commentedon Oct 19, 2026
Related: Website #262 owns compatibility-cohort scaling and rollout decisions. This issue owns workflow/activity process separation within the Python application; it does not replace cohort-aware draining or scaling.
rmcdaniel commentedon Oct 19, 2026
Taking #161 through the runnable example, installed-process qualification and
portal/shared-guide publication in draft #162. Runtime and package versions are
unchanged. The baseline is published Python 2.6.0 with immutable Server 2.9.5.
Actual shared-queue and explicit activity-queue routing, retry, roster/type
observations and graceful shutdown remain to be qualified. Local phase resources
retire by 21:30 UTC; no Cloud or native/shared fixture changes.
rmcdaniel commentedon Oct 19, 2026
SDK portion merged and published in #162:
Separate workflow and activity processes.
Normal installed Python2.6.0 / immutable Server2.9.5 passes the three actual
process cases, retry, explicit queues and clean deregistration. All15 candidate
checks pass, and the connected CI log confirms each new case passed. No SDK
runtime or package release was needed.
The shared English/Ukrainian links are merged in
Website #271
after all six candidate checks passed. Its
deployment39321766632
is live. Maintainer-owned next action is to read back those four public pages
and finish fresh-main source checks before closing this issue. No reporter
action is needed. All local test resources and raw output are retired.
rmcdaniel commentedon Oct 19, 2026
Delivered through SDK #162
and Website #271.
and example source
cover distinct worker IDs, workflow-only/activity-only processes, shared and
explicit activity queues, slot/resource budgets, retry and SIGTERM cleanup.
Local activities, sessions, sticky history and downstream contention retain
their separate contracts.
cases, plus the documented default-queue CLI/inspection commands. Exact
results, retry attempts, type/queue registrations and removed registrations
after exit0 are checked. This is not an arbitrary long-callback drain test.
and all15 fresh-main checks PASS. The actual connected log shows42PASS /
49SKIP and explicitly confirms all three new cases PASS. Portal publication
39321514279 PASS; the public deployment audit names0ed44b85 / SDK2.6.0.
candidate and all seven fresh-main/deployment checks PASS. Actual canonical
English worker,
English admission,
Ukrainian worker
and Ukrainian admission
pages each return200 and contain the published SDK guide link.
The first readback inspected
/docs/2.0/compatibility redirect documents. Theircanonical destinations above were then read directly; this was not a deployment
defect. The earlier local cache setup failure and recovered transient503s remain
explicit in #162. Both merged remote heads are404. All local test containers,
network, database, dependencies, cache, raw output, source worktrees and branches
were removed. No SDK runtime change or package release was needed.