Dapr 1.10.8

This hotfix release contains 8 bug fixes.

• Fixed an issue in Bulk Subscribe when App replied back with few specific kind of replies
• Fixed Dapr accepting components with impossible names in standalone mode
• Fixed an issue with service invocation path decoding
• Fix panic in service invocation when connection to target sidecar fails
• MongoDB Actor State Store: Fixed an issue with storing Actor Reminders
• Fixed a Goroutine leak in Actor reminders and timers.
• Fixed an issue with Service Invocation on Kubernetes clusters with the permission enforcement admission controller enabled.
• Fixed issue with Azure Service Bus binding rejecting messages

Fixed an issue in Bulk Subscribe when App replied back with few specific kind of replies

Problem

When App doesn't acknowledge Bulk Subscribe messages with proper statuses json, then Bulk Subscribe was resulting in panic for components with Default Bulk Subscribe implementation.

Impact

The issue impacts users on Dapr 1.10.x who use Bulk Subscribe feature with a component having Default Bulk Subscribe implementation and their App not replying with proper statuses json.

Root cause

This issue started to occur while introducing Resiliency in Bulk Subscribe, where-in the responses collection was not properly updated.

Solution

Ensuring correct updation of Bulk Subscribe Response collection solved the issue.

Fixed Dapr accepting components with impossible names in standalone mode

Problem

When running in standalone mode, Dapr would parse and accept components which
had impossible names, making them unusable.

Impact

Impacts users running Dapr <= 1.10.7 in standalone mode.

Root cause

Dapr was not validating the component name when running in standalone mode.

Solution

Added validation of the component name when running in standalone mode.
Components with impossible names will be rejected during startup.

Fixed an issue with service invocation path decoding

Problem

Encoded path segments in service invocation requests (e.g.
http://localhost:3500/v1.0/invoke/myapp/method/MyMethod%2F1) were being
decoded by Dapr before being passed to the application. This meant the path
could be routed to the wrong app, or the app would receive a decoded path (
MyMethod/1 in the example above) instead of the encoded path.

Impact

Since v1.10.7, requests to service invocation endpoints with encoded path
segments may be routed to the wrong app, or the app will receive a decoded path
instead of the encoded path.

Root cause

The Dapr HTTP server was decoding the path before passing it to the application.

Solution

We changed the Dapr HTTP server to pass the path to the application without
decoding it.

Fix panic in service invocation when connection to target sidecar fails

Problem

When performing service invocation, a Dapr sidecar could have experienced a panic if the connection to the target sidecar failed to be established.

Impact

This issue impacts users on Dapr 1.10.0-1.10.7.

Root cause

The issue was due to improper error handling of failures to connect to a target sidcar.

Solution

We improved the error handling routines to prevent panics in case of errors while establishing a connection to a target sidecar.

MongoDB Actor State Store: Fixed an issue with storing Actor Reminders

Problem

Actor Reminders without data were stored incorrectly and the empty (null) data was subsequently interpreted as a string value. Everytime an Actor Reminder was updated it reencoded the existing encoding, causing exponential growth in ActorReminder data leading up to the MongoDB document size limit. Other problems include the incorrect storage of the actor reminder period.

Impact

Since v1.10.5 (and also in v1.11.0), Actor Reminders used with MongoDB as Actor State Store were impacted by this bug. While some reminders written or updated with affected versions may work, all reminders written with the impacted versions should be considered unrecoverable as some reminder data may have been corrupted.

Root cause

The issue was related to the usage of BSON as data serialization format for MongoDB. Due to changes in the Dapr runtime introduced in version 1.10.5, reminders data and periods were incorrectly serialized in BSON format.

Solution

We addressed the issues with serializing actor reminder data in BSON format for MongoDB.

Fixed a Goroutine leak in Actor reminders and timers.

Problem

The daprd sidecar process would increase in memory over time when using Actor
reminders and timers.

Impact

Using Actor reminders and timers in Dapr 1.11.0 and earlier could cause a goroutine leak that would grow over time.
This could cause increase CPU utilization and/or memory exhaustion.

Root cause

Goroutines were not being cleaned up when reminders and timers fired or were stopped.

Solution

Goroutines are now cleaned up when reminders and timers are fired.

Fixed an issue with Service Invocation on Kubernetes clusters with the permission enforcement admission controller enabled.

Problem

Updating Dapr from 1.10 to 1.11 on Kubernetes clusters which have the permission enforcement admission controller enabled gives the following error
when using Service Invocation:

unable to create Dapr service for wrapper, service: test/test-dapr, err:
services \"test-dapr\" is forbidden: cannot set blockOwnerDeletion if an
ownerReference refers to a resource you can't set finalizers on:

Impact

Since v1.11.0 Service Invocation on Kubernetes clusters which have the permission enforcement admission controller enabled is unusable.

This is particularly problematic when for OpenShift clusters, as they have this admission controller enabled by default.

Root cause

When using the permission enforcement admission controller on Kubernetes,
Service Invocation fails because the operator is unable to create or update
Services.

Solution

We updated the Kubernetes RBAC permissions used by the Dapr Operator.

Fixed issue with Azure Service Bus binding rejecting messages

Problem

The following error message is logged by Daprd when using the Azure Service Bus binding, and the message will not be sent to the application.

"App handler returned an error for message xxx on queue shipments: error invoking app: Post "http://127.0.0.1:80/xxx": net/http: invalid header field name"

Impact

Since v1.10.4, applications would not receive messages from Azure Service Bus bindings.

Root cause

Azure Service Bus supports storing Application Proprieties which are not URL
safe.

Solution

Daprd encodes metadata headers before sending messages to applications, so that
all data is URL safe.