From e2feb1e820ccfec17a3d30c1e00f6488288fb7ea Mon Sep 17 00:00:00 2001 From: Durable Workflow Date: Tue, 20 Oct 2026 14:57:36 +0000 Subject: [PATCH 1/2] docs: retain recorded queue workers during routing changes --- docs/portal/build/workers.md | 2 ++ docs/portal/operate/deployment.md | 2 ++ 2 files changed, 4 insertions(+) diff --git a/docs/portal/build/workers.md b/docs/portal/build/workers.md index 2ac13bec..190393d8 100644 --- a/docs/portal/build/workers.md +++ b/docs/portal/build/workers.md @@ -91,6 +91,8 @@ Scale a queue by starting more workers with the same registered types and a comp Do not send a workflow to a queue that has no compatible workflow handler. Inspect `listWorkers()` and `describeTaskQueue()` before assuming a deployment received traffic. +An activity option such as `['queue' => 'payments-v2']` selects the queue of a newly scheduled activity execution. The runtime stores that resolved queue; pending activities, their retries and repaired tasks keep it. Changing a worker's `taskQueue` does not move recorded work, and existing workflow runs keep their own workflow queue. Retain compatible workers on old queues while those dependencies remain. Follow the [recorded-queue transition and diagnostics procedure](https://durable-workflow.com/docs/polyglot/task-matching-dispatch#recorded-activity-queues). + ## Let the managed loop own the protocol `Worker::run()` registers, negotiates heartbeat cadence, polls workflow/activity/query tasks, renews workflow-task leases, and reports terminal outcomes. Typed transient poll pressure is retried with capped backoff while registration heartbeats and shutdown checks remain responsive. diff --git a/docs/portal/operate/deployment.md b/docs/portal/operate/deployment.md index de91228e..b60bb9d7 100644 --- a/docs/portal/operate/deployment.md +++ b/docs/portal/operate/deployment.md @@ -50,6 +50,8 @@ Do not use the SDK repository's `main` branch as a production Composer source. I Start new workers before draining the old pool. Keep old and new builds registered only when both can replay the histories routed to that queue. If a change is not replay-compatible, use a new task queue or a worker build-routing plan rather than hoping restarts choose the right code. +A new queue is not a migration of existing runs or activities. Previously scheduled activities, delayed retries and repaired tasks retain their recorded queue; passive runs and continuation chains can still need old workers. Deploy the new pool and routing first, then keep compatible old pools available until their dependencies are accounted for and new work no longer creates them. An empty ready-task count or a fresh registration is not proof of safe retirement. Use the [recorded-queue procedure and existing run/queue diagnostics](https://durable-workflow.com/docs/polyglot/task-matching-dispatch#recorded-activity-queues). Repair does not relocate work or extend its original total deadline. [Server #519](https://github.com/durable-workflow/server/issues/519) tracks the separate guarded retirement capability. + ## Preserve workflow entry arguments Recorded start input must still bind to the deployed workflow entry method. From bb0f9d7323c7806fe4c9f72fb2833279db3f3bbb Mon Sep 17 00:00:00 2001 From: Durable Workflow Date: Tue, 20 Oct 2026 18:22:18 +0000 Subject: [PATCH 2/2] docs: use canonical queue guidance links after publication --- docs/portal/build/workers.md | 2 +- docs/portal/operate/deployment.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/portal/build/workers.md b/docs/portal/build/workers.md index 190393d8..09b605f2 100644 --- a/docs/portal/build/workers.md +++ b/docs/portal/build/workers.md @@ -91,7 +91,7 @@ Scale a queue by starting more workers with the same registered types and a comp Do not send a workflow to a queue that has no compatible workflow handler. Inspect `listWorkers()` and `describeTaskQueue()` before assuming a deployment received traffic. -An activity option such as `['queue' => 'payments-v2']` selects the queue of a newly scheduled activity execution. The runtime stores that resolved queue; pending activities, their retries and repaired tasks keep it. Changing a worker's `taskQueue` does not move recorded work, and existing workflow runs keep their own workflow queue. Retain compatible workers on old queues while those dependencies remain. Follow the [recorded-queue transition and diagnostics procedure](https://durable-workflow.com/docs/polyglot/task-matching-dispatch#recorded-activity-queues). +An activity option such as `['queue' => 'payments-v2']` selects the queue of a newly scheduled activity execution. The runtime stores that resolved queue. Pending activities, their retries and repaired tasks keep it. Changing a worker's `taskQueue` does not move recorded work, and existing workflow runs keep their own workflow queue. Retain compatible workers on old queues while those dependencies remain. Follow the [recorded-queue transition and diagnostics procedure](https://durable-workflow.com/docs/polyglot/task-matching-dispatch/#recorded-activity-queues). ## Let the managed loop own the protocol diff --git a/docs/portal/operate/deployment.md b/docs/portal/operate/deployment.md index b60bb9d7..06ff9d37 100644 --- a/docs/portal/operate/deployment.md +++ b/docs/portal/operate/deployment.md @@ -50,7 +50,7 @@ Do not use the SDK repository's `main` branch as a production Composer source. I Start new workers before draining the old pool. Keep old and new builds registered only when both can replay the histories routed to that queue. If a change is not replay-compatible, use a new task queue or a worker build-routing plan rather than hoping restarts choose the right code. -A new queue is not a migration of existing runs or activities. Previously scheduled activities, delayed retries and repaired tasks retain their recorded queue; passive runs and continuation chains can still need old workers. Deploy the new pool and routing first, then keep compatible old pools available until their dependencies are accounted for and new work no longer creates them. An empty ready-task count or a fresh registration is not proof of safe retirement. Use the [recorded-queue procedure and existing run/queue diagnostics](https://durable-workflow.com/docs/polyglot/task-matching-dispatch#recorded-activity-queues). Repair does not relocate work or extend its original total deadline. [Server #519](https://github.com/durable-workflow/server/issues/519) tracks the separate guarded retirement capability. +A new queue is not a migration of existing runs or activities. Previously scheduled activities, delayed retries and repaired tasks retain their recorded queue. Passive runs and continuation chains can still need old workers. Deploy the new pool and routing first, then keep compatible old pools available until their dependencies are accounted for and new work no longer creates them. An empty ready-task count or a fresh registration is not proof of safe retirement. Use the [recorded-queue procedure and existing run/queue diagnostics](https://durable-workflow.com/docs/polyglot/task-matching-dispatch/#recorded-activity-queues). Repair does not relocate work or extend its original total deadline. [Server #519](https://github.com/durable-workflow/server/issues/519) tracks the separate guarded retirement capability. ## Preserve workflow entry arguments