Tags: temporalio/api-go
Tags
[Worker Versioning GA]: Add autoUpgrade information inside of events … …(#665) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Describe what has changed in this PR --> - Add InheritedAutoUpgradeInfo message and store it inside of StartWorkflowExecutionAttributes. <!-- Tell your future self why have you made these changes --> - So that replication, on the passive cluster, can also use the revision number mechanics and ensure that workflow tasks get dispatched to the correct worker. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** - Discussion to follow <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> - temporalio/temporal#8632
Add RESOURCE_EXHAUSTED_CAUSE_WORKER_DEPLOYMENT_LIMITS (#662) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Describe what has changed in this PR --> **What changed?** Adding a new RESOURCE_EXHAUSTED_CAUSE enum item <!-- Tell your future self why have you made these changes --> **Why?** User in returned ResourceExhausted errors related to worker deployments. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** None <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** temporalio/temporal#8620 is waiting for this API change to merge
WorkerDeployments becoming async in nature. (#647) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Describe what has changed in this PR --> **What changed?** - Added a monotonically increasing counter which shall be used by the history service when scheduling workflow/activity tasks. - Add an enum in the RoutingConfig which shall convey the routing config propagation status. This shall allow users to have a peek at the exact stage where an update, scheduled by a worker-versioning write API, has reached. <!-- Tell your future self why have you made these changes --> **Why?** - The main purpose of this is to resolve out-of-sync history and matching partitions when it comes to deciding how to route tasks <!-- Are there any breaking changes on binary or code level? --> None, just new fields and enums, no new APIs <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** temporalio/temporal#8570 --------- Co-authored-by: Carly de Frondeville <[email protected]>
Add Deployment Options for Eager start (#645) **What changed?** Added `eager_worker_deployment_options` to `StartWorkflowExecutionRequest`. <!-- Tell your future self why have you made these changes --> **Why?** So server knows the versioning info of the worker who would process the eager task. Server can ignore the eager flag if the worker doesn't have the Current version. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** None <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR**
add `ManagerIdentity` field to WorkerDeployment, and API to set/unset… … (#632) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Tell your future self why have you made these changes --> I want the Worker Controller to stop making changes to a Worker Deployment if it detects that another client has written to the same Worker Deployment. This is so that, if a user calls `SetCurrentVersion` or `SetRampingVersion` from the CLI during an incident, the Controller does not overwrite that change. `LastModifiedBy` is not enough for this feature, because we need a way for the "other client" (likely user CLI in most cases, maybe UI if we allow such changes through the UI some day) to indicate to the controller that manual changes are no longer needed and the controller can safely take ownership over writing to this Worker Deployment again. I thought about doing this via a `Metadata` on the Deployment, similar to WorkerDeploymentVersion Metadata, but I can't think of any other use cases for Deployment-level metadata, and I think this is load-bearing enough to deserve it's own field, where we can clearly document semantics. <!-- Are there any breaking changes on binary or code level? --> No <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> Not implemented in server yet because this is just a proposal
bug: add timestamp to TriggerImmediatelyRequest (#606) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Describe what has changed in this PR --> **What changed?** adding a timestamp to `TriggerImmediatelyRequest` message <!-- Tell your future self why have you made these changes --> We can make the wft “more idempotent”: put the desired trigger time in the trigger immediately request itself, so it goes in the signal payload, so all wfts attempt to start the target with the same id. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> [**Server PR**](temporalio/temporal#7968)
Add DescribeWorker API (#624) <!-- 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)
Add worker visibility API - RecordWorkerHeartbeat and ListWorkers (#601) <!-- Describe what has changed in this PR --> **What changed?** What changed? * 2 new APIs added: * WorkerHeartbeat * ListWorkerStatus * WorkerInfo information added to: * ShutDownWorker request * Poll(Activity|Nexus|Workflow)TaskQueue requests This is "for merge". Here is a previous PR, where we discuss this at length: temporalio/api#599 <!-- Tell your future self why have you made these changes --> **Why?** Part of the worker visibility work. Workers should be able to report their status. Users should be able to get information about workers. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** Yes - new API is introduce. <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** [Server PR](temporalio/temporal#7870)
PreviousNext