Conversation
rkannan82
force-pushed
the
kannan/add-worker-instance-key-to-wft-complete
branch
from
76cff4d to
d940f4e
Compare
rkannan82
force-pushed
the
kannan/add-worker-instance-key-to-wft-complete
branch
from
d940f4e to
6fb0a9a
Compare
rkannan82
changed the title
rkannan82
force-pushed
the
kannan/add-worker-instance-key-to-wft-complete
branch
from
6fb0a9a to
3425c98
Compare
cretz
left a comment
cretz
left a comment
There was a problem hiding this comment.
No big blockers, though I noticed the "Server PR" section of the PR template was removed from the description of this PR. I do think we should wait for most of server impl to understand this has everything needed (no use merging before then).
rkannan82
force-pushed
the
kannan/add-worker-instance-key-to-wft-complete
branch
from
98f7a60 to
61952c9
Compare
cretz
left a comment
cretz
left a comment
There was a problem hiding this comment.
LGTM, but mentioned in last review, the "Server PR" section removed from description template, would like to see implementation get a bit further and linked if possible
Chad, How can I make progress on the server PRs without submitting this API change? I might have asked this before, but what is the recommended protocol? Should I have started the server PRs in my own repo (forked) and have that reference this unsubmitted
I added the server PR to the description. temporalio/temporal#9231 |
This enables the server to track which worker is executing eager-dispatched activities, allowing activity cancellation to be routed correctly.
rkannan82
force-pushed
the
kannan/add-worker-instance-key-to-wft-complete
branch
from
61952c9 to
98350a9
Compare
Yeah, basically this. It just means you have a PR mostly done but referencing your API branch instead of API master. It's just a good way to make sure we don't "oh yeah" during implementation (even when we think we're so sure what we want from he API). May be able to ask server peers on common approach here, e.g. feature branches. |
yuandrew
left a comment
yuandrew
left a comment
There was a problem hiding this comment.
LGTM, but agree with Chad on server-side PR being close to merging before this goes in
…nstance-key-to-wft-complete
…comment Made-with: Cursor
rkannan82
changed the title
Clarify that this is a dedicated per-worker Nexus task queue for receiving control tasks like activity cancellation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…edRequest resource_id already uses field 18. Renumber worker_instance_key to 19 and worker_control_task_queue to 20. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Resolves merge conflicts in executions.proto, mutable_state_impl_test.go, and go.sum. Updates api-go replace directive to 5423d0dd678a which includes the worker control task queue attributes from temporalio/api#711. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Match the comment style from temporalio/api#711. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…711) <!-- Describe what has changed in this PR --> **What changed?** Added worker_control_task_queue to poll requests: - PollActivityTaskQueueRequest - PollWorkflowTaskQueueRequest Note: worker_instance_key was already added to these requests in #686. Added worker_instance_key and worker_control_task_queue to: - RespondWorkflowTaskCompletedRequest: This API is used to eagerly fetch activity. <!-- Tell your future self why have you made these changes --> **Why?** To enable server to send control tasks to worker. Each worker provides a worker_control_task_queue (a dedicated per-worker Nexus task queue) so the server can send control tasks directly to it. Example flow: - User cancels a workflow. - Server sends activity cancellation tasks to all workers that could be processing activities belonging to that workflow. - Worker will receive the cancellation message even when activity heartbeat is not enabled. <!-- Are there any breaking changes on binary or code level? --> Breaking changes: None [Server PR](temporalio/temporal#9231) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
5 participants
What changed?
Added worker_control_task_queue to poll requests:
Note: worker_instance_key was already added to these requests in Enhance ShutdownWorkerRequest and poll calls with worker_instance_key #686.
Added worker_instance_key and worker_control_task_queue to:
Why?
To enable server to send control tasks to worker. Each worker provides a worker_control_task_queue (a dedicated per-worker Nexus task queue) so the server can send control tasks directly to it.
Example flow:
Breaking changes: None
Server PR