v3.6 to 3.7

Breaking Changes

Behavioral Improvements / Fixes

ApplicationSet webhook responses now match the API server webhook

The ApplicationSet controller's webhook endpoint now handles requests the same way as the API server's /api/webhook endpoint:

Payloads larger than the webhook.maxPayloadSizeMB value in the argocd-cm ConfigMap (default 50MB) are rejected with 400 Bad Request. Previously, the ApplicationSet webhook had no payload size limit.
A GHCR event that fails signature verification is rejected with 401 Unauthorized instead of 400 Bad Request.
When a payload cannot be parsed, the response body is a generic Webhook processing failed message. The parser error is logged by the ApplicationSet controller instead of being returned to the caller.

If you monitor the ApplicationSet webhook's response codes or bodies, update any checks that relied on the previous behavior.

Other Changes

Revoked token resync interval

argocd-server now reloads revoked tokens from Redis every 5 minutes instead of every 15 seconds. The interval is configurable with ARGOCD_SESSION_REVOKED_TOKEN_RESYNC_DURATION. See Revoked token resync.

`--http-retry-max` now applies to TLS (and `--grpc-web`) connections

Prior to v3.7, the CLI's global --http-retry-max flag had no effect on TLS connections (the default) — the retryable HTTP transport was silently discarded during TLS setup, so retries only ever applied to --plaintext connections. This is now fixed, so --http-retry-max retries transient failures (connection errors, HTTP 429, and 5xx except 501) for HTTP requests over plaintext or TLS, including --grpc-web. (Native gRPC connections use a separate, built-in retry interceptor that this flag does not configure.)

The flag still defaults to 0 (no retries), so behavior is unchanged unless you have opted in. If you do set --http-retry-max, be aware:

Warning

Retries apply to all gRPC-web requests, including non-idempotent ones. gRPC-web tunnels every RPC as an HTTP POST, so the retry layer cannot distinguish reads from writes. A transient 5xx returned after the server has already processed a mutating request (e.g. argocd account generate-token, argocd app actions run) will cause the request to be re-sent. Prefer enabling the flag for idempotent/declarative operations (e.g. app set/app sync), and consider this before enabling it globally for mutating commands.
Retries add latency ahead of any command-level timeout. Backoff is capped at 10s per attempt, but --http-retry-max attempts still accumulate; size it with your --timeout values (e.g. app sync/app wait) in mind.