CLI mutations fail on deployments with sub-second worker queues (isLowLatency dropped from v1.0 API spec)

[seanmuth]

Summary

Any CLI mutation against a deployment that has sub-second pipelines enabled fails with:

Error: Invalid request: Deployments with sub second pipelines enabled must have at least one worker queue with sub second pipelines enabled

This affects every mutating command — even ones unrelated to worker queues or sub-second — including:

• astro deployment variable update
• astro deployment variable create
• astro deployment worker-queue update

The sub-second queue is correctly configured in the UI. The server-side validation is correct. The bug is in the CLI.

Root Cause

isLowLatency was added to the v1alpha1 OpenAPI spec but was never promoted to the v1.0 spec. The CLI's Go client is generated from the v1.0 spec, so the field is absent from all generated structs. Every outgoing mutation request effectively sends isLowLatency: false on all worker queues, which the server correctly rejects.

Spec gap:

• versionedapi_v1.0.yaml — WorkerQueue, UpdateWorkerQueueRequest, WorkerQueueRequest all missing isLowLatency
• public_v1alpha1.yaml — same three types correctly define isLowLatency: boolean

Generated client (stale): astro-client-v1/api.gen.go

• WorkerQueue struct — no IsLowLatency
• UpdateWorkerQueueRequest struct — no IsLowLatency
• WorkerQueueRequest struct — no IsLowLatency

Mapping sites where the field gets dropped:

• cloud/deployment/deployment.go ~line 975: ConvertWorkerQueues (standard/dedicated path)
• cloud/deployment/deployment.go ~line 1200: ConvertWorkerQueues (hybrid path)
• cloud/deployment/deployment.go ~line 1375: ConvertCreateQueuesToUpdate
• cloud/deployment/workerqueue/workerqueue.go ~line 85: CreateOrUpdate building existingQueueRequest

The existing queue data is read back from the API correctly (via v1alpha1 which has the field), but the field is dropped when reconstructing the outgoing v1.0 request.

Fix

1. Add isLowLatency: boolean to WorkerQueue, UpdateWorkerQueueRequest, and WorkerQueueRequest in versionedapi_v1.0.yaml
2. Run make generate to regenerate astro-client-v1/api.gen.go
3. Wire IsLowLatency: q.IsLowLatency at the four mapping sites listed above

Workaround

None via CLI. Affected users must make all deployment changes through the Astro UI until this is fixed.

Environment

• astro-cli v1.43.1 (latest)
• Deployment: AstroExecutor, Runtime 3.2-5, sub-second pipelines enabled (Labs)

---

Identified with Claude Sonnet 4.6

[seanmuth]

Correction: root cause is server-side, not the CLI

After tracing the actual code in both astro-cli and astronomer/astro, my initial diagnosis above was wrong. There is no viable CLI-side fix. Corrected analysis:

What's actually happening

• The CLI manages worker queues exclusively through the versioned v1.0 client (astrov1): it reads existing queues, rebuilds them as WorkerQueueRequest, and PUTs the full list via deployment.Update.
• isLowLatency (sub second) is a v1alpha1-only field. On the server, only models/controllers/v1alpha1/worker_queues.go maps it. The versionedapi (v1.0) controller — apps/core/models/controllers/versionedapi/worker_queues.go — has no isLowLatency on CommonWorkerQueueRequest/UpdateWorkerQueueRequest, and its NewMutateWorkerQueueInput() never sets MutateWorkerQueueInput.IsLowLatency.
• So every v1.0 update sends IsLowLatency = nil for all queues. ValidateWorkerQueueLowLatency (services/platform/shared/deployments/deployment_utils.go) then sees zero low-latency queues on a sub-second deployment and rejects with the error in this issue.

Why the CLI can't fix it: even if the CLI added the field and sent it, the v1.0 server handler has no field to receive it and drops it before validation. The v1.0 spec omission is deliberate — sub-second is a Labs/v1alpha1 feature.

Fix (server-side): carry forward each queue's existing IsLowLatency from the DB when a v1.0 update omits it, so v1.0 updates are non-destructive without exposing the Labs field on GA. PR against astronomer/astro incoming; will cross-link here.

Workaround until then: make changes to sub-second deployments via the Astro UI (v1alpha1) rather than the CLI.

Suggest relabeling/transferring this to the astronomer/astro core-API team.

Corrected with Claude Opus 4.8

[ashb]

The cli side fix would be to switch to a PATCH style end point when one exists