Dapr 1.16.16

This update contains bug fixes:

• Sentry fails to sign certificates when the issuer key type does not match the CSR signature algorithm
• Helm downgrade from 1.17 or 1.18 fails on the scheduler StatefulSet storage size

Sentry fails to sign certificates when the issuer key type does not match the CSR signature algorithm

Problem

Sentry crashes on startup with:

fatal: error running Sentry: failed to retrieve the initial identity: x509: requested SignatureAlgorithm does not match private key type

This occurs when the trust bundle issuer key type does not match the key type used in certificate signing requests. Dapr 1.18 generates Ed25519 issuer keys, while 1.16 generates ECDSA keys and ECDSA-signed CSRs.

Impact

Any 1.16 control plane whose dapr-trust-bundle secret was generated by Dapr 1.18 is affected, most commonly after a downgrade from 1.18 to 1.16 on the same cluster.

Root Cause

Sentry copied the SignatureAlgorithm from the incoming CSR onto the workload certificate template. When x509.CreateCertificate was called, Go's x509 library rejected the mismatch between the template's signature algorithm (derived from the CSR key type) and the issuer's private key type.

Solution

Removed the SignatureAlgorithm from certificate templates and the SignRequest struct, backporting the fix released in Dapr 1.17.2. Go's x509.CreateCertificate now infers the correct signature algorithm from the issuer's signing key, allowing sentry to sign certificates regardless of the CSR's key type. A regression test covers signing an ECDSA-keyed identity with an Ed25519 issuer key.

Helm downgrade from 1.17 or 1.18 fails on the scheduler StatefulSet storage size

Problem

Downgrading a Dapr control plane from 1.17 or 1.18 to 1.16 with Helm fails with:

StatefulSet.apps "dapr-scheduler-server" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'ordinals', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden

Impact

Clusters installed on Dapr 1.17 or 1.18, where the scheduler chart defaults the persistent volume claim size to 16Gi, cannot be downgraded to 1.16 without manually passing --set dapr_scheduler.cluster.storageSize=<live size> or deleting the StatefulSet with --cascade=orphan first.

Root Cause

The 1.16 chart rendered spec.volumeClaimTemplates storage directly from .Values.cluster.storageSize (default 1Gi). StatefulSet.spec.volumeClaimTemplates is immutable in Kubernetes, so rendering any size other than the one already deployed causes the API server to reject the patch.

Solution

Backported the dapr_scheduler.storageSize template helper from the 1.17 chart. The chart now looks up the live dapr-scheduler-server StatefulSet and pins the rendered storage request to the value already in use, falling back to .Values.cluster.storageSize for fresh installs.

Downgrade guidance

When downgrading to 1.16.16 with Helm, prefer --reset-values and explicitly re-pass the values the install was created with (for example global.ha.enabled). Avoid --reuse-values: it carries forward the previous chart's computed defaults, some of which are invalid for 1.16 binaries. In particular, the 1.17 and 1.18 charts default the placement disseminateTimeout to 8s, which the 1.16 placement binary rejects at startup (valid range 1s to 3s).