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

This hotfix release contains seven bug fixes. 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. 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. 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. 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. In the first releases of Dapr 1.10, a bug was preventing Workflows from working when using the . In this situation, workflow activity invocations would fail with a "duplicate invocation" error. This would cause the workflow to stall indefinitely. 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". 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. We addressed the underlying issue in Dapr 1.10.3 and added more tests to prevent future regressions. 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

This issue impacts users on Dapr 1.10.0-1.10.2 that use Azure Service Bus components. The issue was traced to a bug in an upstream SDK. 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. A regression introduced in Dapr 1.8.0 accidentally removed support for authenticating with Kafka components using a certificate, without password or mTLS. The issue impacts users on Dapr 1.8.0-1.10.2 that use Kafka components and want to use a certificate for authentication. Support for the feature was accidentally removed in Dapr 1.8.0 due to a bug. We restored support for authenticating with Kafka components using a certificate, and we added more tests to prevent future regressions. 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. This impact users on Dapr 1.10.0-1.10.2 using NATS JetStream. 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 We reverted the code change for NATS JetStream, so that no default queue group or consumer group value is assigned. 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. This impacts users on Dapr 1.10.0-1.10.2 using redirect 3xx http status code responses in their app. The switch to use the Go net/http client library instead of fasthhtp caused the http client to automatically handle redirects. We disabled the redirect handle and returned the original response to the caller. 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`. This impacts users on Dapr 1.10.0-1.10.2 that invoke applications using Dapr and the gRPC protocol. 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`. We fixed the issue that caused Dapr to ignore the response body in case of error, for both HTTP and gRPC service invocation.