Adding --gcp-cloud-run-scale-down-wait-time flag

[seanbollin]

Related issues

Closes: https://temporalio.atlassian.net/browse/COM-241

What changed?

Adds --gcp-cloud-run-scale-down-wait-time to temporal worker deployment create-version
and temporal worker deployment update-version-compute-config.

• The flag is a duration (e.g. 90s, 5m), matching the CLI's convention for
  time-valued flags (cliext.FlagDuration, like --schedule-to-close-timeout,
  --retention, etc.). 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-wait-time must all be set together.
• Behavior: after the scaler last saw unmet task demand, it waits this long before
  it may scale the Cloud Run worker pool down. Raising it keeps the pool from
  scaling down before long-running or bursty activities finish. Defaults to 90s
  when unset; 0s disables the wait.
• The CLI converts the duration to milliseconds and sends it under the rate-based
  scaler's existing no_sync_quiet_ms config key, which WCI already validates and
  applies — no server-side change is required.
• describe-version surfaces the value (JSON scaleDownWaitTimeMs, in ms, and the
  one-line compute-config summary).

This is a stopgap for long/bursty activities pending GCP's configurable graceful
shutdown; it is not itself graceful shutdown.

Checklist

Stability

• Breaking changes are marked with 💥 in the PR title and release notes — no breaking changes; the flag joins an as-yet-unreleased flag group
• Changes to JSON output (-o json / -o jsonl) are treated as breaking changes — see note 1

Design

• This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server)
• New commands follow temporal <noun> <verb> structure — no new commands; flag added to existing commands
• New flags are named after the API concept, not the implementation mechanism — scale-down-wait-time names the user-facing behavior, not the internal no_sync_quiet_ms key
• New flags don't duplicate an existing flag that serves the same purpose
• New flags do not have short aliases without strong justification — no alias added
• Experimental features are marked with (Experimental) in commands.yaml — both commands already carry a "This is an experimental feature" note in their descriptions

Help text (see style guide at the top of commands.yaml)

• All flags shown in help text and examples are implemented and functional — the GCP examples now include the 5th flag so they stay copy-pasteable
• Summaries use sentence case and have no trailing period — no new command summaries
• Long descriptions end with a period and include at least one example invocation — no new command descriptions; the flag help ends with a period
• Examples use long flags (--namespace, not -n), one flag per line
• Placeholder values use YourXxx form (YourWorkflowId, YourNamespace)

Behavior

• Results go to stdout; errors and warnings go to stderr
• Error messages are lowercase with no trailing punctuation

Tests

• Added functional test(s) (SharedServerSuite)
• Added unit test(s) (func TestXxx) where applicable

Notes for reviewer

1. JSON output: describe-version gains an additive scaleDownWaitTimeMs field
   (milliseconds). The surrounding GCP scaler config block is not in a tagged
   release yet, so no released output changes — hence not marked 💥.
2. The flag is a duration; the underlying WCI key (no_sync_quiet_ms) and the
   describe output stay in milliseconds. Runtime effect on WCI was verified
   separately via an in-process integration test in temporal-auto-scaled-workers
   (confirms WCI reads the value and blocks scale-down with
   scale_block_reason=no_sync_quiet); that test is not part of this CLI PR.

Manual tests

Built locally, ran commands to review help info
WCI integration test locally to see changed values took effect

Once approved I'm going to test locally with a real Cloud Run deployment (don't want to test multiple times if there is any feedback - I'll address that first then test)

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[chatgpt-codex-connector]

💡 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".

[chatgpt-codex-connector]

Remove the worker-pool co-requirement from this help

For update-version-compute-config, this says the new flag is only valid when --gcp-cloud-run-worker-pool is supplied, but the command's documented and implemented scaler-only mode accepts the five scaler flags without any provider flags and updates only scaler.details. A user following this option-level help may unnecessarily supply all required provider fields and overwrite the provider configuration rather than performing the intended scaler-only update.

Useful? React with 👍 / 👎.

[seanbollin]

Fixed

[chatgpt-codex-connector]

💡 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".

[chatgpt-codex-connector]

Validate durations before truncating to milliseconds

When the flag is given a negative sub-millisecond value such as --gcp-cloud-run-scale-down-wait-time=-1us, Duration().Milliseconds() truncates it to zero, so the later negative-value check is bypassed and no_sync_quiet_ms: 0 is sent, disabling the wait instead of rejecting the input. Positive sub-millisecond values are likewise silently changed to zero; validate the original duration before converting (in both create and update helpers), and either reject or explicitly handle non-integral milliseconds.

Useful? React with 👍 / 👎.

[seanbollin]

Fixed

[gcristea-temporal]

This looks good, thank you for taking adding the extra argument.

Not sure whether my review approval alone is enough for you to merge.

[chaptersix]

please use the PR template that demos the UX difference.

[jaypipes]

I would suggest using --scale-down-stabilization-window or --scale-down-stabilization-duration to align with the identical Kubernetes autoscaler settings.