Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
This is the release candidate 1.13.0-rc.4
This is the release candidate 1.13.0-rc.3
The Azure Event Hubs bindings and pubsub components may fail in such a way that for one or multiple subscribed topics no further events will be received.
Impacts users running Dapr 1.12.4 or earlier that use Azure EventHubs bindings or pubsub components. The dapr sidecar error message Error from event processor indicates that this problem has been encountered.
Under certain failure scenarios (including networking interruption) the Event Hubs event processor for a particular subscription topic can return an error. When this occurs the error is logged once, existing partition clients will terminate with errors and no further partition clients will be allocated. At this point the subscription for this topic effectively ends with no attempt to restart the subscription. This however does not impact other sidecar functionality and the sidecar continues to report healthy status.
Added error handling for the topic event processor host to restart the entire subscription loop for this topic 5 seconds after an error is encountered.
When using the Service Invocation API, HTTP calls that returned non-200 responses from target apps would contain duplicate headers.
Impacts users running Dapr 1.12.0 - 1.12.4 and using Service Invocation with HTTP.
Dapr did not check if headers were already added in non-successful responses.
Dapr was changed to not include headers if they already exist when sending the response back to the calling app.
Pub/Sub brokers that returned a content-length metadata might cause an app's gRPC server to reject the request because the size of the data returned from the broker is different than the size of the request Dapr is sending to the app.
Impacts users running Dapr 1.x using Pub/Sub brokers that support delivering custom headers, in combination with publishers that included a content-length metadata.
Dapr did not remove the content-length header, if such existed, before sending the request to gRPC-enabled apps.
In accordance to gRPC recommendations, the content-length metadata was removed from the message Dapr is sending to the app.
When using client-side state encryoption in self-hosted mode, decryption operations would cause Dapr to panic and exit.
Impacts users running Dapr 1.12.x using client-side state encryption in self-hosted mode.
A regression in Dapr caused the metadata information containing the name of the decryption key to become empty.
The code causing the regression was reverted and the decryption key name became available again, allowing for decryption of data to succeed.
This is the release candidate 1.13.0-rc.2
This is the release candidate 1.13.0-rc.1
This update includes bug fixes:
When restarting a significant deployment on Kubernetes (> 20 pods), many pods will be removed from placement table. When the restarts happens concurrently with leadership changes in placement service, the placement table can get into a corrupt state that requires the restart of placement service #7311
Impacts users running Dapr 1.12.0-1.12.3 that uses actors and deployments with many sidecar instances.
Race condition between placement leadership changes and placement table updates due to pods being terminated.
Mitigate by reducing the chances of leadership changes in placement service and fix a bug that can cause terminated pods to remain in placement table forever.
When performing service invocation to another app using Dapr (using either HTTP or gRPC), the caller sidecar establishes a gRPC connection with the target sidecar. When the target app is deployed with multiple replicas (scaled horizontally), a connection is established with each replica and requests are load-balanced across all replicas.
In Dapr 1.12.3 and lower running on Kubernetes, due to the way this logic was implemented, if the connection with one of the replicas became idle, it would have caused the connection between the caller sidecar and all replicas to be severed, possibly interrupting other in-flight service invocation calls.
This issue impacts users running Dapr 1.12.3 and lower, running on Kubernetes, that use service invocation to invoke apps that are scaled horizontally.
This issue does not impact users that are running outside of Kubernetes or who are using other Dapr nameresolution components (including mDNS or Consul).
On Kubernetes, the gRPC connection was established with the DNS name of the target Service, and we allowed the gRPC-Go library to perform name resolution with the Kubernetes DNS server and establish a connection with each replica. When the connection with one of the replicas becomes idle, the caller app receives a "GOAWAY" message which is interpreted as a signal to terminate all connections with all replicas of the app.
We have changed the internals of service invocation, so we always perform DNS resolution in the caller Dapr sidecar, also on Kubernetes. The gRPC-Go library receives an individual IP address to connect to, so "GOAWAY" messages only impact the connection with an individual replica.
This is the release candidate 1.12.4-rc.1
This update includes bug fixes:
In HTTP service invocation, in certain cases when a resiliency policy is applied (for example, one that includes timeouts), requests could be interrupted earlier with a "context deadline exceeded" error.
Impacts users running Dapr 1.12.0-1.12.2 that use HTTP service invocation and who have resiliency policies applied
When resiliency policies with timeouts are applied, due to a bug the incorrect context was used while sending the response to the client, and in certain situations it could have been terminated earlier than the request.
We fixed the code that handles HTTP service invocation to make sure the timeout is applied to the entire response.
Placement nodes acquire a lock, disseminate the tables, and release the lock in parallel. The Placement stream disconnects before the dissemination of tables.
Error invoke actor method: failed to invoke target x after 3 retries
Placement server logs:
level=error msg="Stream is disconnected before member is added
Impacts users running Dapr 1.12.0-1.12.2
Dissemination did not use a background context. The logic to acquire a lock, disseminate the tables, and release the lock were all occurring in parallel.
Updated the Dapr Placement service to use a background context and follow a 3 step process to acquire a lock, disseminate the tables, and release the lock.
When using a database with a case-sensitive collation, the SQL Server state store component did not work correctly. Certain operations, including those relied upon by the actor state store, were failing.
Impacts users of Dapr 1.11.0-1.12.2
A stored procedure referenced a column named with the wrong case. This was causing errors on case-sensitive databases.
We updated the stored procedure so it does use the correct case for column names.
When using Dapr with Kafka for Pub/Sub and subscribing to multiple topics, users might see bottlenecks in Kafka message processing and long init times when the Dapr sidecar is starting up.
Impacts users of Dapr 1.11.0-1.12.2
When new topic subscriptions were added, Dapr would close the consumer group and recreate it, leading to partition rebalance across the cluster.
The Kafka consumer logic was changed to not recreate the consumer group every time a new topic subscription is added.
This is the release candidate 1.12.3-rc.2
This is the release candidate 1.12.3-rc.1