Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.5.1.md

This release addresses several issues with the following fixes: Adds retry logic for TooManyRequests initialization error for CosmosDb State and Binding components (https://github.com/dapr/components-contrib/pull/1329) Add scopes to Pub/Sub subscription conversion from `v1alpha1` to `v2alpha1` (https://github.com/dapr/dapr/issues/3914) Upgrade `github.com/nhooyr/websocket` to > 1.8.6 with DoS vulnerability fixes (https://github.com/dapr/dapr/pull/3892) Fixing race conditions in RabbitMQ Pub/Sub component (https://github.com/dapr/components-contrib/pull/1278) Fixing crash on subscribe in Configuration API Preview (https://github.com/dapr/dapr/issues/3970) Fix connection leak for gRPC connections in Dapr Operator (https://github.com/dapr/dapr/pull/3752) Fixing hanging shutdown calls when using Unix Domain Socket (https://github.com/dapr/dapr/issues/3894) Important: If upgrading to this version using Helm instead of the Dapr CLI, you will need to update the Subscription CRD prior to performing the Helm upgrade. ```cli kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/v1.4.4/charts/dapr/crds/subscription.yaml ``` New strongly advised production guidance for Azure Cosmos DB components have been established. Dapr now retries connecting to Azure Cosmos DB during sidecar initialization. Some sidecars with Azure Cosmos DB components (both Output Binding and State Store) fail to initialize, causing the sidecar to restart or hang (up to the `initTimeout` duration which is 5 seconds by default). Sidecar logs show a response from Cosmos DB with status `429 Request rate too large`. Every new connection to Azure Cosmos DB initially performs a large number of metadata requests (). The metadata request rate limit for Azure Cosmos DB Accounts can easily be exceeded when multiple connections to the same Azure Cosmos DB account (even distinct datatabases within the same account) are made simultaneously. If the attempt to initialize the component and connect to Azure Cosmos DB fails due to this rate limit Dapr did not previously retry the connection until the sidecar restarts. The following production best practices must be applied to minimize the likelihood this issue will occur: Ensure applications and sidecars only load the Azure Cosmos DB component when it is required for that application, which avoid unnecessary database connections from other microservices or applications. This can be done by . Choose deployment strategies that sequentially deploy or start all applications to minimize bursts in new connections to your Azure Cosmos DB accounts. Avoid reusing the same Azure Cosmos DB account for unrelated databases or systems (even outside of Dapr). Distinct Azure Cosmos DB accounts have distinct rate limits. Additionally, Dapr now retries establishing the initial Azure Cosmos DB connection for up to 5 minutes, when the component is configured by setting the `initTimeout` value. The default component initialization timeout is 5 seconds. Please update your specifying a greater `initTimeout` duration value for the component to attempt reconnections. Note that this will delay the readiness of your

In Kubernetes you may need to . In order to add the Pub/Sub routing preview feature, the subscriptions CRD required a new version `v2alpha1`. This requires the Dapr operator to provide a conversion webhook that converts `v1alpha1` to `v2alpha1`. Subscriptions created as `v1alpha1` would drop the scopes when converted by the operator to `v2alpha1`. The conversion function was not copying the `Scopes` field from `v1apha1` to `v2alpha1`. The conversion function was updated to include copying the `Scopes` field. From : is a minimal and idiomatic WebSocket library for Go. Affected versions of this package are vulnerable to Denial of Service (DoS). A double channel close panic is possible if a peer sent back multiple pongs for every ping. If the second pong arrived before the ping goroutine deleted its channel from the map, the channel would be closed twice and a panic would occur. Dapr was using v1.8.6 of the package. The package was upgrade to v1.8.7. The implementation of RabbitMQ Pub/Sub component was not robust, especially when an application used multiple publishers/subscribers. Concurrent calls to the underlying AMQP layer caused race condition and failures in publishing and subscribing This hotfix extends thread synchronization to span across entire "pubish" and "subscribe" operations. This eliminates race conditions between publishers and subscribers during access to the underlying AMQP layer. In addition this hotfix adds a comprehensive certification test for RabbitMQ Pub/Sub component. A successful completion of the test indicates that the component has reached the stable state. The `SubscribeConfigurationAlpha1` method is used to subscribe to configuration updates. Invoking the `SubscribeConfigurationAlpha1` method causes Dapr to crash. The implementation had an uninitialized map which would cause a nil-memory panic. The fix initializes the map properly and allows apps to be notified about changes to a configuration item. When a large number of pods are destroyed frequently, the server side needs to actively detect whether the connection is available to prevent the leakage of operator channel resources. Error message can look like: ```txt time="..." level=warning msg="error updating sidecar with component ...: rpc error: code = Unavailable desc = transport is closing" instance=dapr-operator-abc-xyz scope=dapr.operator.api type=log ver=unknown ``` Dapr operator does not close stale connections. Dapr operator actively detects whether grpc connection to sidecar is active. When using Unix Domain Sockets the Shutdown call hangs requiring the app to be manually terminated. The library used in the implementation of this feature did not automatically close idle HTTP connections. Added shutdown logic to explicitly close idle HTTP connections. Applications using the `1.4.x` release of Dapr should consider taking the related `1.4.4` release (or higher) that addresses a similar set of issues.