Uh oh!
There was an error while loading. Please reload this page.
Add one-time move to the versioning override API! - #808
Conversation
| // Indicates whether to override the workflow to be AutoUpgrade or Pinned. | ||
| oneof override { | ||
| // Override the workflow to have Pinned behavior. | ||
| PinnedOverride pinned = 3; |
There was a problem hiding this comment.
so this would continue to be sticky pin behavior? I think we need to update the doc so it is more clear. It would ignore even when SDK do CAN and wants change to AU to current version?
There was a problem hiding this comment.
It would ignore even when SDK do CAN and wants change to AU to current version
yes, the PinnedOverride is meant to be sticky. As long as it exists on a workflow execution, it shall be pinned to a specific workflow execution
Uh oh!
There was an error while loading. Please reload this page.
Sushisource
left a comment
There was a problem hiding this comment.
I think the comments do a great job explaining it all now.
Opengrep — new findings
Suppress findingsAdd a |
Uh oh!
There was an error while loading. Please reload this page.
## Related issues <!-- Closes#123 --> ## What changed? - WISOTT - For more information, you can also view the relevant PR's: 1. Server PR: temporalio/temporal#10763 2. API PR: temporalio/api#808 ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [ ] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [x] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [x] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [x] New flags don't duplicate an existing flag that serves the same purpose - [x] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [x] Results go to stdout; errors and warnings go to stderr - [x] Error messages are lowercase with no trailing punctuation **Tests** - [x] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable ## Manual tests **Setup** Requires a server that includes temporalio/temporal#10763 and a workflow whose Task Queue is present in the target Worker Deployment Version. ```bash temporal server start-dev --headless temporal workflow start \ --type YourWorkflowType \ --task-queue YourTaskQueue \ --workflow-id YourWorkflowId ``` Use an existing Worker Deployment Version for the target: ```text Deployment name: YourDeploymentName Build ID: YourBuildId ``` **Happy path** ```bash temporal workflow update-options \ --workflow-id YourWorkflowId \ --versioning-override-behavior one_time \ --versioning-override-deployment-name YourDeploymentName \ --versioning-override-build-id YourBuildId ``` Expected output: ```text Update workflow options succeeded ``` Verify table output: ```bash temporal workflow describe \ --workflow-id YourWorkflowId ``` Expected: `OverrideBehavior` is `OneTime`, with `OverrideTargetVersionDeploymentName` and `OverrideTargetVersionBuildId` set. Verify JSON output: ```bash temporal workflow describe \ --workflow-id YourWorkflowId \ --output json ``` Expected: `versioningInfo.versioningOverride.oneTime.targetDeploymentVersion` contains the deployment name and build ID. **Error case** ```bash temporal workflow update-options \ --workflow-id YourWorkflowId \ --versioning-override-behavior one_time ``` Expected: ```text Error: missing deployment name and/or build id with 'one_time' behavior ``` ```bash echo $? ``` Expected: ```text 1 ``` **Composition** ```bash temporal workflow update-options \ --query 'WorkflowId = "YourWorkflowId"' \ --yes \ --versioning-override-behavior one_time \ --versioning-override-deployment-name YourDeploymentName \ --versioning-override-build-id YourBuildId ``` Expected: a batch update-options job is started. Use `temporal batch describe` to inspect the batch, then `temporal workflow describe` on an affected Workflow Execution to verify the one-time override.
What changed?
Why?
Breaking changes
Server PR