Adding --gcp-cloud-run-scale-down-stabilization-duration flag - #1167
Conversation
|
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 37bae511f3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 99856f6bd4
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
99856f6 to
d8a362a
Compare
gcristea-temporal
left a comment
There was a problem hiding this comment.
This looks good, thank you for taking adding the extra argument.
Not sure whether my review approval alone is enough for you to merge.
|
please use the PR template that demos the UX difference. |
jaypipes
left a comment
There was a problem hiding this comment.
I would suggest using --scale-down-stabilization-window or --scale-down-stabilization-duration to align with the identical Kubernetes autoscaler settings.
d8a362a to
ca11705
Compare
ca11705 to
eb1ac89
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eb1ac89aa4
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
…yment version commands Exposes the rate-based scaler's scale-down stabilization window (previously hard-coded to 90s) as --gcp-cloud-run-scale-down-stabilization-duration on `temporal worker deployment create-version` and `update-version-compute-config`, so worker pools running long or bursty activities aren't scaled down before in-flight work finishes. The flag is a duration and joins the existing all-or-none GCP Cloud Run scaler group; the CLI converts it to milliseconds and sends it under the rate-based scaler's no_sync_quiet_ms config key, so no server-side change is required. describe-version surfaces the value as a duration string. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
52945d4 to
92f242b
Compare
The CLI settled on a duration flag, --gcp-cloud-run-scale-down-stabilization-duration, which takes 5m or 90s. A millisecond field in the UI asks users to convert the value in their head, and the two surfaces then describe one setting in two units. Use the Holocene duration input for the field, the same control the schedule forms use. The form holds a seconds duration string such as 90s, and the page converts to milliseconds when it builds the compute config, so the wire key no_sync_quiet_ms is unchanged. The edit form converts back, and the unit selector opens on the largest whole unit, so a stored 300000 ms reads as 5 minutes. The field accepts a whole number of milliseconds, which agrees with the CLI. A sub-millisecond value is rejected rather than rounded. Refs: temporalio/cli#1167
# Backport for CLI v1.8.3 (monthly public/latest) Cuts the scheduled monthly public/latest release onto `release/1.8.x`, which was sitting exactly on `v1.8.2` with nothing backported since 2026-07-31. **The governing constraint:** this release keeps the embedded dev server on OSS Server **v1.31.2**. Everything below follows from that. `main` has moved to server `v1.32.0-162.0` (a Cloud tag) and `go.temporal.io/api` v1.63.x, so `main` is not publicly releasable and a large share of recent work cannot ship here. ## Summary Of the 29 commits on `main` since `v1.8.2`: | | Count | |---|---| | Cherry-picked as-is | 13 | | Dependency bumps folded into one commit | 5 | | New commits authored for this backport | 2 | | Excluded | 11 | Verified: `go build ./...` and `cliext` build clean, `make gen` produces no diff, full `go test ./...` green, binary reports `Server 1.31.2, UI 2.50.1`. ## Included ### Cherry-picked from `main` | Commit | Change | |---|---| | #1153 | test: fix concurrent start test assertions | | #1140 | Gate AWS Lambda role/external-id behind `--aws-lambda-skip-role-and-external-id` | | #1137 | Delegate help and completion to extensions when applicable | | #1167 | Add `--gcp-cloud-run-scale-down-stabilization-duration` | | #1176 | Fix cliext build, add it to CI workflow | | #1149 | chore(deps): bump the github-actions group with 3 updates | | #1162 | chore(deps): bump docker/login-action 4.4.0 → 4.5.2 | | #1166 | chore(deps): bump docker/login-action 4.5.2 → 4.6.0 | | #1156 | fix(activity): remove no-op `reset-attempts` flag — **adjusted, see below** | | #1061 | feat: add `temporal options` command and declutter help output | | #1171 | test: stabilize activity list pagination | | #1186 | fix: document `start-dev` `--log-level` default | | #1177 | Support AWS AgentCore compute provider | The last three merged to `main` on 2026-09-01, after the initial backport set was assembled, and all three cherry-pick cleanly with no dependency movement. **#1177 (AgentCore)** is a new feature rather than a fix, so it warrants a deliberate look. It carries no api v1.63.x dependency: the provider type is the plain string `"aws-agentcore"` and the provider details are an opaque `map[string]any` encoded to a `commonpb.Payload`. Server v1.31.2 does not validate the provider type — it forwards it as `wciiface.ComputeProviderType` — so acceptance is decided by Cloud-side WCI, not by anything this release pins. Its functional test is `t.Skip`-ed pending AWS fixtures, which matches the existing Lambda and GCP Cloud Run compute-provider tests. **#1171** needed one addition on this line: its new `TestActivity_List_Pagination` calls `activity.GetInfo(ctx)`, and the `go.temporal.io/sdk/activity` import is present on `main` but not in this file on `release/1.8.x`. The import is folded into the #1171 pick so each commit builds standalone. ### New commits **`backport: pin compatible dependency set and adjust #1156 for 1.8.x`** Dependency bumps are applied directly rather than cherry-picked, because taking them as-is pulls `go.temporal.io/api` past what server v1.31.2 can compile against (see *Dependency ceiling* below). Covers the isatty, x/tools, grpc, echo and testify bumps (#1145, #1148, #1132, #1175, #1174). Also pins `cliext` to a **tagged** SDK. `main` currently pins `go.temporal.io/sdk v1.46.1-0.20260720184640-f34dc3da35ab` — a commit SHA — in `cliext/go.mod`, which reaches the root build through `replace github.com/temporalio/cli/cliext => ./cliext`. That violates the tagged-dependencies rule for a public release. **`main` should be fixed separately.** **`fix(activity): use correct update-mask path for --task-queue`** Fixes a real, currently-shipping bug. `v1.8.2` sends update-mask path `task_queue_name`, which the server's `ParseFieldMask` normalizes to `taskQueueName` and which never matches its `taskQueue.name` key — so `temporal activity update-options --task-queue` **silently does nothing**. Verified A/B against the embedded server v1.31.2: - with `task_queue.name` → task queue updates as expected - with `task_queue_name` (what v1.8.2 ships) → unchanged The fix exists upstream only inside #1092, which cannot be backported, so it is extracted here as a one-liner. ## Dependency ceiling `server v1.31.2` **does not compile** against `go.temporal.io/api` ≥ **v1.62.10**: that release adds `CountNexusOperationExecutions` to the `WorkflowServiceClient` interface, which v1.31.2's `clientImpl`, `metricClient` and `retryableClient` do not implement. Because api is a transitive dependency, Go's minimal version selection drags it upward whenever anything that depends on it is bumped. That caps everything: | Dependency | Ceiling | Reason | |---|---|---| | `go.temporal.io/api` | v1.62.9 | v1.62.10 breaks server v1.31.2 | | `github.com/temporalio/ui-server/v2` | v2.50.1 | v2.51.0 → api v1.62.13; v2.53.x → api v1.63.x | | `go.temporal.io/sdk` | v1.42.0 | v1.43.1 → api v1.62.12; v1.46.0 → api v1.63.x | | `go.temporal.io/sdk/contrib/envconfig` | v1.0.0 | v1.0.1 changed `DefaultConfigFilePath` to one return value; `cliext/config.oauth.go` expects two | Resulting set — every Temporal direct dependency unchanged from `v1.8.2` except an api patch bump: ``` go.temporal.io/api v1.62.9 (was v1.62.8) go.temporal.io/server v1.31.2 unchanged go.temporal.io/sdk v1.41.1 unchanged go.temporal.io/sdk/contrib/envconfig v1.0.0 unchanged github.com/temporalio/ui-server/v2 v2.50.1 unchanged ``` **Note for the UI team:** this release ships **UI Server v2.50.1, unchanged**. The natural assumption would be v2.53.3, but that requires api v1.63.5. ## Excluded, and why ### Requires OSS Server v1.32.x / api v1.63.x | Commit | Reason | |---|---| | #1172 bump server for Nexus Query support | The server bump itself — out of scope for this line | | #1092 single SAA operator actions | Uses `Pause/Unpause/Reset ActivityExecutionRequest` and `UpdateActivityExecutionOptionsRequest`, absent from api v1.62.x | | #1152 enable SAA operator and batch commands in dev server | Needs `activity.EnableStandaloneActivityOperatorCommands` and `dynamicconfig.FrontendEnableBatchOperationsForStandaloneActivities`, absent from server v1.31.2 | | #1159 drop `activity unpause --reset-attempts`/`--reset-heartbeats` | Authored on top of #1092; its diff context already uses the new RPC names | | #1150 reject `update-options --start-delay` for workflow Activities | Needs `ActivityOptions.StartDelay`, new in api v1.63.5, via unbackported prerequisite #1113 | | #1131 render links on activity describe | Needs `ActivityExecutionInfo.GetLinks` and `DescribeActivityExecutionResponse.GetCallbacks`, new in api v1.63.5 | | #1151 bump UI server v2.53.1 | Requires api v1.63.4 | | #1164 bump UI server v2.53.3 | Requires api v1.63.5 | ### Excluded for other reasons **#1114 — staged connection diagnosis for opaque dial failures.** Depends on #1017 (*Unwrap System Nexus Operations in event history*), which introduced `dialClientWithCodec` and was never backported. On `release/1.8.x` only the two-value `dialClient` exists, and git silently misapplies #1114's hunks into it, producing three-value returns from a two-value function. Pulling in #1017 is too large for a patch release. **#1158 — docs: clarify `--query` targets Workflow Activities.** Pure documentation describing Standalone Activity semantics ("Omit `--workflow-id` to target a Standalone Activity…"). That behavior does not exist on this line, so backporting it would ship misleading help text. **#1155 — fix(activity): include options in batch `update-options`.** The change itself is correct, but batch `update-options` applies **nothing** on server v1.31.2. Probed directly: after a batch run, task queue is unchanged and `schedule_to_close_timeout` is still `0s`. Its new test `TestActivityOptionsUpdate_BatchMatchAll` fails consistently (3/3). Deferred to the release that carries the server bump. ## Reviewer notes **#1156 was adjusted rather than taken verbatim.** Upstream, `activity reset` had already lost `--reset-heartbeats` to an earlier SAA commit, so taking `main`'s version would have removed both flags at once. Only `--reset-attempts` is a no-op, the surviving help text still documents `--reset-heartbeats`, and its removal belongs to #1159 (excluded). This backport therefore removes only `--reset-attempts` and keeps the batch path on `c.ResetHeartbeats` rather than hardcoding `true`. Worth a careful look. **Known flaky test.** `TestHelp_AllFlag_ShorterCommandPathWinsi` failed on one full-suite run and passed on the next; it passes 5/5 in isolation. It arrives with #1137 and exists identically on `main`, so it is inherited rather than introduced — but expect occasional red CI. **Pre-existing `go vet` findings** (two lock-copy, one context leak) are byte-identical to the `v1.8.2` baseline. Not introduced here. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Alex Stanfield <13949480+chaptersix@users.noreply.github.com> Co-authored-by: Nanook <nanookclaw@users.noreply.github.com> Co-authored-by: mani-j9 <mani.janumpally@temporal.io> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Jeri Lane <jeri.lane@temporal.io> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Sean Bollin <sean@sean-bollin.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Sean Kane <spkane31@gmail.com> Co-authored-by: Ross Nelson <axcess1@me.com> Co-authored-by: dryrun <dryrun@local> Co-authored-by: justinschoeff <justin.schoeff@temporal.io>
Related issues
Closes: https://temporalio.atlassian.net/browse/COM-241
What changed?
Adds
--gcp-cloud-run-scale-down-stabilization-durationtotemporal worker deployment create-versionandtemporal worker deployment update-version-compute-config.UX difference: the GCP Cloud Run scaler's scale-down stabilization window was
previously hard-coded to 90s, so a worker pool running long or bursty activities
could be scaled down out from under in-flight work. Users can now configure it:
Details:
90s,5m,10m), matching the CLI's conventionfor time-valued flags (
cliext.FlagDuration, like--schedule-to-close-timeout,--retention). It joins the existing all-or-none GCP Cloud Run scaler group, so--gcp-cloud-run-min-instances,--gcp-cloud-run-max-instances,--gcp-cloud-run-initial-instances,--gcp-cloud-run-utilization-target, and--gcp-cloud-run-scale-down-stabilization-durationmust all be set together.it may scale the pool down. Defaults to
90swhen unset;0sdisables the wait.scaler's existing
no_sync_quiet_msconfig key, which the server (WCI) alreadyvalidates and applies — no server-side change is required.
describe-versionsurfaces the value as a duration string (JSONscaleDownStabilization, e.g."5m 0s", formatted the same way as scheduledurations; the text summary shows the same).
Checklist
Stability
-o json/-o jsonl) are treated as breaking changes —describe-versiongains an additivescaleDownStabilizationMsfield; the GCP scaler JSON block is not in a tagged release yet, so no released output changesDesign
temporal <noun> <verb>structure — no new commands; flag added to existing commandsscale-down-stabilization-durationnames the behavior (cf. k8s HPA "stabilization window"), not the internalno_sync_quiet_mskey(Experimental)incommands.yaml— both commands already carry a "This is an experimental feature" noteHelp text (see style guide at the top of
commands.yaml)--namespace, not-n), one flag per lineYourXxxform (YourWorkflowId,YourNamespace)Behavior
Tests
SharedServerSuite) — group/negative/sub-millisecond/wrong-provider cases inTestCreateWorkerDeploymentVersion_Errors; carried in...UpdateModesfunc TestXxx) —TestGCPCloudRunScalerDetails,TestFormatComputeConfigProto_ScalerBoundsManual tests
Setup
Happy path
Error case
Composition