Dapr 1.10.3

This hotfix release contains seven bug fixes.

• Fixes Dapr starting without middlewares when one component in the pipeline fails to init
• Fixes handling of "continue-as-new" for Dapr Workflows
• Fixes issues with Azure Service Bus components not recovering after failures
• Restores support for certificate authentication without password or mTLS in Kafka
• Fixed issues with NATS JetStream when no subscription name is specified
• Fixed Dapr to hand over redirects to application
• Fixes error message lost in service invocation

Fixes Dapr starting without middlewares when one component in the pipeline fails to init

Problem

When Dapr sidecars are configured to include middlewares, either for the "Dapr" HTTP pipeline or for the "app" HTTP pipeline, a failure in initializing one of the components in the pipeline caused Dapr to start without any middleware configured for that pipeline, with only a warning-level log shown.
Instead, Dapr should have respected the ignoreErrors property of components (with a default of false) to decide if the sidecar could have started without that individual middleware (like for any other kinds of components). Additionally, if ignoreErrors is true, only the failed components should have been excluded from the pipeline, and the other ones should have continued to be included.

Impact

The issue impacts users on Dapr 1.10.2 and earlier who use middleware components, for both the "Dapr" HTTP pipeline and the "app" HTTP pipeline.

Root cause

In the Dapr runtime, the methods initializing middleware components behaved differently from the methods that initialized all other kinds of Dapr components.
For middlewares, the value of ignoreErrors in the components' spec was ignored and assumed to be true in all cases; the default should have been false. With ignoreErrors set to false, the Dapr sidecar should have refused to start if one of the middlewares failed to initialize.
If a component had ignoreErrors set to true, instead, Dapr should have continued initializing excluding only the impacted component; instead, the runtime was excluding all components in the middleware pipeline when one failed to initialize.

Solution

We have changed the methods that initialize the HTTP middleware pipelines to be aligned with the behavior of the other component kinds. Tests have been added to prevent future regressions.

Fixes handling of "continue-as-new" for Dapr Workflows

Problem

In the first releases of Dapr 1.10, a bug was preventing Workflows from working when using the "continue-as-new" feature. In this situation, workflow activity invocations would fail with a "duplicate invocation" error. This would cause the workflow to stall indefinitely.

Impact

This issue impacts users on Dapr 1.10.0-1.10.2 that are using Dapr Workflows (alpha) and want to build workflows that use "continue-as-new".

Root cause

An error in the implementation of Dapr Workflows prevented caused the "continue-as-new" feature not to work and the workflow invocations to fail as if they were duplicate.

Solution

We addressed the underlying issue in Dapr 1.10.3 and added more tests to prevent future regressions.

Fixes issues with Azure Service Bus components not recovering after failures

Problem

In certain cases, the connection with Azure Service Bus could not be recovered automatically after a failure. Users reported seeing error messages containing $cbs node has already been opened, requiring a restart of the Dapr sidecar.

Impact

This issue impacts users on Dapr 1.10.0-1.10.2 that use Azure Service Bus components.

Root cause

The issue was traced to a bug in an upstream SDK.

Solution

We worked with the vendors of the upstream SDK to address the issue and include a new version of the SDK in Dapr 1.10.3.

Restores support for certificate authentication without password or mTLS in Kafka

Problem

A regression introduced in Dapr 1.8.0 accidentally removed support for authenticating with Kafka components using a certificate, without password or mTLS.

Impact

The issue impacts users on Dapr 1.8.0-1.10.2 that use Kafka components and want to use a certificate for authentication.

Root cause

Support for the feature was accidentally removed in Dapr 1.8.0 due to a bug.

Solution

We restored support for authenticating with Kafka components using a certificate, and we added more tests to prevent future regressions.

Fixed issues with NATS JetStream when no subscription name is specified

Problem

NATS JetStream components cannot be initialized when no subscription name is specified. Users would encounter errors with failures to create a subscription for a delivery group that is not a configured queue group.

Impact

This impact users on Dapr 1.10.0-1.10.2 using NATS JetStream.

Root cause

The Dapr Runtime injects a default consumer group name when none is specified. A code refactor standardized the use of this value when no consumer group was specified in all PubSub components. This behavior however was incorrect NATS JetStream

Solution

We reverted the code change for NATS JetStream, so that no default queue group or consumer group value is assigned.

Fixed automatic redirection handling

Problem

Dapr automatically handles redirects when the application is invoked using the http protocol. This is not the expected behavior as applications should handle redirects themselves.

Impact

This impacts users on Dapr 1.10.0-1.10.2 using redirect 3xx http status code responses in their app.

Root cause

The switch to use the Go net/http client library instead of fasthhtp caused the http client to automatically handle redirects.

Solution

We disabled the redirect handle and returned the original response to the caller.

Fixes error message lost in service invocation

Problem

When Dapr invokes an application using the gRPC protocol that returns an error message, the returned error message is lost and replaced with message is nil.

Impact

This impacts users on Dapr 1.10.0-1.10.2 that invoke applications using Dapr and the gRPC protocol.

Root cause

As part of a change introduced in Dapr 1.10, Dapr was incorrectly discarding the response body when the application returned a non-successful status code. In the case of HTTP service invocation, the response body was silently ignored; in the case of gRPC, it was replaced with message is nil.

Solution

We fixed the issue that caused Dapr to ignore the response body in case of error, for both HTTP and gRPC service invocation.