Dapr 1.12.5

Azure Event Hubs bindings and pubsub silently fail to recover subscriptions during event processor failures

Problem

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.

Impact

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.

Root cause

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.

Solution

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.

Service invocation calls return duplicate headers on non-200 responses

Problem

When using the Service Invocation API, HTTP calls that returned non-200 responses from target apps would contain duplicate headers.

Impact

Impacts users running Dapr 1.12.0 - 1.12.4 and using Service Invocation with HTTP.

Root cause

Dapr did not check if headers were already added in non-successful responses.

Solution

Dapr was changed to not include headers if they already exist when sending the response back to the calling app.

Pub-sub messages containing a content-length metadata from the broker would fail a consuming gRPC app

Problem

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.

Impact

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.

Root cause

Dapr did not remove the content-length header, if such existed, before sending the request to gRPC-enabled apps.

Solution

In accordance to gRPC recommendations, the content-length metadata was removed from the message Dapr is sending to the app.

Automatic client-side state encryption would panic on state decryption in self-hosted mode

Problem

When using client-side state encryoption in self-hosted mode, decryption operations would cause Dapr to panic and exit.

Impact

Impacts users running Dapr 1.12.x using client-side state encryption in self-hosted mode.

Root cause

A regression in Dapr caused the metadata information containing the name of the decryption key to become empty.

Solution

The code causing the regression was reverted and the decryption key name became available again, allowing for decryption of data to succeed.