Tags: temporalio/api
Tags
[Workflow Pause]: Add api/v1 support (#705) <!-- Describe what has changed in this PR --> **What changed?** Adds versioned API endpoint support for `PauseWorkflowExecution` and `UnpauseWorkflowExecution` operations by adding `/api/v1/` HTTP bindings alongside the existing unversioned paths. <!-- Tell your future self why have you made these changes --> **Why?** The Go server configuration in [UI](https://github.com/temporalio/ui) currently groups all API routes under `/api/v1/`.
[Workflow Pause]: Add api/v1 support (#705) <!-- Describe what has changed in this PR --> **What changed?** Adds versioned API endpoint support for `PauseWorkflowExecution` and `UnpauseWorkflowExecution` operations by adding `/api/v1/` HTTP bindings alongside the existing unversioned paths. <!-- Tell your future self why have you made these changes --> **Why?** The Go server configuration in [UI](https://github.com/temporalio/ui) currently groups all API routes under `/api/v1/`.
Make version optional for versioning override of already-pinned workf… …lows (#687) _**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 --> Make version optional for versioning override of already-pinned workflows <!-- Tell your future self why have you made these changes --> So that people don't have to specify a version if they just mean "pin to what you're already pinned to." Someone could use this if they want to set pinned overrides on a batch of workflows that are pinned to different versions, and the user wants to prevent these workflows from upgrading-on-CaN (since Pinned override is inherited on CaN, they would not upgrade-on-CaN) <!-- 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#8885
[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 <carly.defrondeville@temporal.io>
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 <carly.defrondeville@temporal.io>
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**
PreviousNext