Add worker commands payloads #622
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cretz
reviewed
Jul 24, 2025
cretz
reviewed
Jul 24, 2025
cretz
reviewed
Jul 24, 2025
temporal/api/worker/v1/message.proto
Outdated
| // Will be send to the worker as a payload of the UpdateWorkerConfig command. | ||
| message UpdateWorkerConfigCommandPayload { | ||
| // Worker identifier, should be unique for the namespace. | ||
| repeated string worker_instance_key = 1; |
There was a problem hiding this comment.
To confirm, you can only update worker config if the server knows about the worker. So if you say "update worker config for every worker on X process", if a specific worker on that process hasn't heartbeat, it doesn't get the update? I think this is probably ok, just want to confirm that is the expected behavior.
There was a problem hiding this comment.
yes, it doesn't get an update.
But that will be very weird situation - heartbeats are coming via the same nexus poll request...
dnr
reviewed
Jul 24, 2025
2 tasks
cretz
reviewed
Jul 24, 2025
Sushisource
reviewed
Jul 24, 2025
Sushisource
reviewed
Jul 24, 2025
Sushisource
reviewed
Jul 24, 2025
Sushisource
reviewed
Jul 24, 2025
Merged
Sushisource
reviewed
Jul 25, 2025
ychebotarev
added a commit
that referenced
this pull request
Jul 25, 2025
<!-- Describe what has changed in this PR --> **What changed?** Add DescribeWorker API. Extracted from [this PR](#622). <!-- Tell your future self why have you made these changes --> DescribeWorker - will be needed to get all the heartbeat information from the worker. Partially this can be covered by "ListWorkers" with query "WorkerInstanceKey = 'xxx'", but this is a dedicated API that doesn't require query processing. Extracting into separate PR so that one is concentrated on worker payload only. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** Introduce new API <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> [Server PR](temporalio/temporal#8094)
temporal-cicd bot
pushed a commit
to temporalio/api-go
that referenced
this pull request
Jul 25, 2025
<!-- Describe what has changed in this PR --> **What changed?** Add DescribeWorker API. Extracted from [this PR](temporalio/api#622). <!-- Tell your future self why have you made these changes --> DescribeWorker - will be needed to get all the heartbeat information from the worker. Partially this can be covered by "ListWorkers" with query "WorkerInstanceKey = 'xxx'", but this is a dedicated API that doesn't require query processing. Extracting into separate PR so that one is concentrated on worker payload only. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** Introduce new API <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> [Server PR](temporalio/temporal#8094)
ychebotarev
force-pushed
the
y_worker_commands
branch
from
56400c8 to
a96cd01
Compare
ychebotarev
added a commit
to temporalio/temporal
that referenced
this pull request
Jul 25, 2025
## What changed? * Add implementation for DescribeWorker API (to both frontend and matching) * Add feature flag * Add all quotas/etc. * Add unit tests * Add functional tests ## Why? Part of worker commands work. Users should be able to directly get worker info for the worker they need. Corresponding API PR: temporalio/api#622 ## How did you test it? - [X] add unit tests - [X] add functional tests ## Potential risks None, behind feature flag
ychebotarev
force-pushed
the
y_worker_commands
branch
from
a96cd01 to
ee2bd59
Compare
yuandrew
reviewed
Jul 29, 2025
| // --) | ||
|
|
||
| // Will be sent to the worker as a payload of the FetchWorkerConfig command. | ||
| message FetchWorkerConfigRequest { |
There was a problem hiding this comment.
I feel like it's a little confusing that these are named the exact same name as the request they're used for, could we differentiate them slightly? Maybe add in Command, Payload, or Nexus into the name?
There was a problem hiding this comment.
we need "Request/Response" pair. "Command" is fine for "Request", but what about "Response"?
Or you mean we should name them
FetchWorkerConfigCommand[Request/Resonse] ? If so I'm fine with that.
There was a problem hiding this comment.
Or FetchWorkerConfig[Request|Response]Payload? Which is exactly what it is
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changed?
Add payloads for worker commands:
FetchWorkerConfig
UpdateWorkerConfig
Also add DescribeWorker API.
Why?
payloads - we need to align with SDK on command payload schemas.
DescribeWorker - will be needed to get all the heartbeat information from the worker.
Partially this can be covered by "ListWorkers" with query "WorkerInstanceKey = 'xxx'", but this is a dedicated API that doesn't require query processing.
Breaking changes
Yes (new API)
Server PR