Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
This update includes bug fixes:
Published messages to HTTP application server report a content-length error and are not processed.
PubSub messages from some PubSubs cannot be processed by the application.
The content-length reported by the PubSub broker message was copied to the message sent to the application's HTTP server. This content-length may not match the final message length sent to the application's HTTP server, resulting in the mesage being rejected.
Filter out the content-length header from the PubSub broker message before sending it to the application's HTTP server.
During a blocked shutdown, all in-flight PubSub messages are cancelled and cannot be processed by the application or the applications processes status discarded.
During shutdown, in-flight messages which are currently being processed by the application cannot be completed.
During shutdown, all publish calls to the application where being cancelled.
PubSub messages are now published to the application in an isolated routine, which is not cancelled during blocked shutdown.
When using Avro schema validation with the Kafka pub/sub component, consuming messages with a null value will fail and not be delivered to the app, and publishing messages with null values will fail.
Kafka messages with null values for both consumers and publishers are not delivered or published when using the Avro schema validation feature.
The Dapr component did not have correct handling of null values in a message.
Handling of null values was added when serializing and deserializing messages.
This is the release candidate 1.13.2-rc.1
This update includes bug fixes:
The operator becomes DDoSed by the Dapr runtime, and an extreme amount of logs are generated. Component hot-reloading no longer functions.
Users running Dapr 1.13.0 that have the Component Hot-Reloading feature gate enabled.
A tight loop in the daprd operator client stream re-establishment causes runtime to constantly create new Component update streams.
Fix the tight loop by correctly breaking out of retries after a successful re-establishment. Also ensures daprd will re-reconcile all Components in the event of a stream re-establishment, catching any Components which might have been deleted while the stream was down.
We're happy to announce the release of Dapr 1.13!
We would like to extend our thanks to all the new and existing contributors who helped make this release happen.
If you're new to Dapr, visit the getting started page and familiarize yourself with Dapr.
Docs have been updated with all the new features and changes of this release. To get started with new capabilities introduced in this release, go to the Concepts and the Developing applications.
Note: This release contains a few breaking changes.
See this section on upgrading Dapr to version 1.13.
These are the v1.13 release highlights:
Component "Hot Reloading" is a new preview feature that, when enabled, allows component updates to be picked up automatically, without the need for restarting the Dapr process. The component spec is reconciled and takes effect when running in both Kubernetes and Self-Hosted modes.
You can now use Go and JavaScript/TypeScript to write fault-tolerant, workflow-based apps with durable execution. See the Go SDK for more details and try the Quickstart or the examples. See the Javascript SDK for more details and try the Quickstart or the examples
You can now opt-in to make actor reminders data use protobuf serialization instead of JSON, which increases throughput, reduces latency, and improves stability when multiple Dapr instances are operating on the same reminders. With this feature enabled, we have observed improvements as high as 40% in Actor Reminders and Workflow benchmarks. This serialization method will become default in v1.14.
Important: Once you enable this feature, you should not downgrade the Dapr control plane to an earlier version, as your reminders data may become unreadable.
To enable protobuf serialization for actor reminders, set the following Helm argument on Kubernetes: dapr_placement.maxActorApiLevel=20
.
On self-hosted mode, run daprd with the flag: --max-api-level=20
Dapr now includes an optional setting to enable low cardinality for metrics emitted by the HTTP server, which will be enabled by default in Dapr 1.14.
Currently, the Dapr HTTP server emits metrics for each request path, which has been observed to cause significant memory usage and have other negative performance impact. When low-cardinality metrics are enabled, the HTTP Dapr server behaves more like the gRPC server and groups requests for each Dapr API together, possibly reducing memory consumption significantly. See additional info here.
Dapr now accepts a dapr.io/block-shutdown-duration
annotation or --dapr-block-shutdown-duration
CLI flag which delays the full shutdown procedure for this duration or until the app reports as unhealthy- whichever is sooner.
During this period, all Subscriptions and input bindings will be closed.
This is useful for applications that need to use the Dapr APIs as part of their own shutdown procedure.
See additional info here.
The Dapr PubSub and State APIs now have the appropriate and standardized error codes returned to applications including enriched error details based on gRPC's richer error model. The remaining APIs are a work in progress, and community contributions towards this effort are greatly appreciated and very impactful. See additional info on the error codes here. Check the docs for each SDK for per-SDK error code parsing and handling. See an example of the Go SDK error parsing and handling here.
You can now use Rust to run Dapr Actors, a programming model for highly scalable stateful applications. See the Rust SDK for more details
You can now use a SQLite based name resolver for service invocation in self-hosted mode. This is useful for dealing with corporate firewalls and VPNs that filter mDNS. See additional info here.
PostgreSQL has a new v2 implementation which contains improvements to performance and reliability. New applications are encouraged to use v2. The v1 implementation remains supported and is not deprecated. There is no migration path from v1 to v2. See additional info here.
Azure Blob Storage has a new v2 implementation, which is recommended for all new projects as it fixes a backwards-incompatible bug with key prefixes. The v1 implementation remains supported and is not deprecated. There is no migration path from v1 to v2. See additional info here.
Thanks to everyone who made this release possible!
@a-elsheikh, @addjuarez, @AishwaryaBalyaya01, @alfred-mikhael, @amimimor, @andreas-eriksson, @andrew-hillier, @arthbalete, @artursouza, @ASHIQUEMD, @avo-sepp, @baransonmez, @berndverst, @bkc, @bmelbourne, @bruth, @burhan, @cgillum, @chaitanyab2311, @cicoyle, @ckcd, @cscetbon, @danielgerlag, @dasanind, @DeepanshuA, @ejba, @elena-kolevska, @emctl, @eunicecompra, @famarting, @farshaddavoudi, @fazledyn-or, @filintod, @frankbuckley, @frodera, @fvandillen, @fyzact, @georgestevens99, @Gonzoe79, @greenie-msft, @gspadotto, @hauju, @henrikkarstrom, @heunghingwan, @hhunter-ms, @ItalyPaleAle, @jamesmcroft, @jancespivo, @jellis18, @jerinthomas1404, @jhberge, @jigargandhi, @jjcollinge, @jorimvanhove, @JoshVanL, @kaibocai, @KarstenWintermann, @KrylixZA, @litan1106, @lrascao, @lucus-sun, @luigirende, @macel94, @marcduiker, @martbln, @mathieu-benoit, @mikeee, @MregXN, @msfussell, @mukundansundar, @nitroin, @olitomlinson, @paianish62, @passuied, @paulyuk, @philliphoff, @pngan, @prashantrewar, @prateek041, @pravinpushkar, @qustavo, @rabollin, @robertojrojas, @RyanLettieri, @sadath-12, @salaboy, @shivamkm07, @shubham1172, @sicoyle, @siebenluke, @skyao, @srilasya02, @srparupu, @stuartleeks, @Taction, @thapasusheel, @tlund101, @tmacam, @toneill818, @TWEESTY, @twinguy, @vermillionsword, @Viktorsubota, @willvelida, @WhitWaldo, @XavierGeerinck, @xiangpingjiang, @yaron2, @yash-nisar, @ytimocin
ghcr.io
in Helm chart 6413 7176
priorityClass
in Helm charts 7103 7395
dapr_sidecar_injector.enableK8sDownwardAPIs
to improve detection of pod IP in certain Kubernetes environments 7511
--dapr-block-shutdown-duration
to daprd 7268 4313
grpc_server_status
label missing for gRPC server latency metric 7045 7255
deploymentAnnotations
produces invalid Helm chart 7194
RenameReminder
methods 6711 6945
AppChannelAllowInsecureTLS
feature flag, and require TLS-enabled app channel to use TLS 1.2+ 7292 7149
content-length
metadata in pubsub subscription. 7413 7421
Dapr 1.13 introduces 3 new components:
Additionally, one component has been removed:
Other improvements and fixes to components:
ttl
is now an alias for ttlInSeconds
and accepts a Go duration format in addition to seconds as whole numbers 3122
disableEntityManagement
metadata option to work with minimal Microsoft Entra ID permissions 3213
EnableHostVerification
3230
~/.dapr
given 777 permisions. 1317
wait
method is now deprecated and will be removed in a future release. The automatic outbound health check covers this use case.dapr-ext-workflow
)Dapr 1.13 Quickstarts include these major updates:
Other improvements include:
process.env.STATE_STORE_NAME
958
To upgrade to this release of Dapr, follow the steps here to ensure a smooth upgrade. You know, the one where you don't get red errors on the terminal.. we all hate that, right?
Uninstall Dapr using the CLI you currently have installed. Note that this will remove the default $HOME/.dapr directory, binaries and all containers dapr_redis, dapr_placement and dapr_zipkin. Linux users need to run sudo if docker command needs sudo:
dapr uninstall --all
For RC releases like this, download the latest and greatest release from here and put the dapr
binary in your PATH.
Once you have installed the CLI, run:
dapr init --runtime-version=1.13
Wait for the update to finish, ensure you are using the latest version of Dapr(1.13) with:
$ dapr --version
CLI version: 1.13
Runtime version: 1.13
You can perform zero-downtime upgrades using both Helm 3 and the Dapr CLI.
Download the latest RC release from here and put the dapr
binary in your PATH.
To upgrade Dapr, run:
dapr upgrade --runtime-version 1.13 -k
To upgrade with high availability mode:
dapr upgrade --runtime-version 1.13 --enable-ha=true -k
Wait until the operation is finished and check your status with dapr status -k
.
All done!
Note: Make sure your deployments are restarted to pick the latest version of the Dapr sidecar
To upgrade Dapr using Helm, run:
helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
helm upgrade dapr dapr/dapr --version 1.13 --namespace=dapr-system --wait
Wait until the operation is finished and check your status with dapr status -k
.
All done!
Note: Make sure your deployments are restarted to pick the latest version of the Dapr sidecar
Please see how to deploy Dapr on a Kubernetes cluster for a complete guide to installing Dapr on Kubernetes
You can use Helm 3 to install Dapr:
helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
kubectl create namespace dapr-system
helm install dapr dapr/dapr --version 1.13 --namespace dapr-system --wait
Alternatively, you can use the latest version of CLI:
dapr init --runtime-version=1.13 -k
Verify the control plane pods are running and are healthy:
$ dapr status -k
NAME NAMESPACE HEALTHY STATUS REPLICAS VERSION AGE CREATED
dapr-sidecar-injector dapr-system True Running 1 1.13 15s 2024-02-26 13:07.39
dapr-sentry dapr-system True Running 1 1.13 15s 2024-02-26 13:07.39
dapr-operator dapr-system True Running 1 1.13 15s 2024-02-26 13:07.39
dapr-placement dapr-system True Running 1 1.13 15s 2024-02-26 13:07.39
After Dapr 1.13 has been installed, perform a rolling restart for your deployments to pick up the new version of the sidecar. This can be done with:
kubectl rollout restart deploy/<deployment-name>
RenameReminder
methods have been removed from the Dapr Actor APIs and SDKs dapr#6711
AppChannelAllowInsecureTLS
feature flag has been removed. The Dapr app channel now requires TLS 1.2 or higher when TLS is enabled, and this behavior cannot be disabled dapr#7149
INVALID_ARGUMENT
, FAILED_PRECONDITION
) instead of the generic UNKNOWN
Additional breaking changes for the Dapr .NET SDK:
1.13
or later.JsonDerivedType
attribute specifying the derived response class.
Alternatively, a custom IJsonTypeInfoResolver
implementation can be set on the JsonSerializerOptions.TypeInfoResolver
property adding a JsonDerivedType
instance to the JsonPolymorphismOptions.DerivedTypes
property on the JsonTypeInfo.PolymorphismOptions
property.JsonDerivedType
attribute or JsonPolymorphismOptions
on a custom IJsonTypeInfoResolver
implementation, Dapr does not ship a .NET 7 target of the SDK. Hence, a .NET 7 consumer application uses the .NET 6 target of the Dapr SDK. Therefore, this breaking change only applies when upgrading a consumer application to .NET 8.typeDiscriminator
on the JsonDerivedType
attribute.The .NET 6 and .NET 8 targets of the Dapr .NET SDK have different serialization behavior of properties of a derived response object on an operation of a weakly-typed actor client.
Impacts users upgrading a consumer application to .NET 8 running Dapr 1.13
or later.
In the .NET 6 target of the SDK, the actor runtime serializes the response object on an operation of a weakly-typed actor client using the runtime type of the response object. In the .NET 8 target of the SDK, the actor runtime serializes the response object using the base response type as declared on the operation on the actor interface.
For .NET 8, the programmer must decorate the base response class that is declared on the operation on the actor interface with a JsonDerivedType
attribute specifying the derived response class.
Alternatively, a custom IJsonTypeInfoResolver
implementation can be set on the JsonSerializerOptions.TypeInfoResolver
property adding a JsonDerivedType
instance to the JsonPolymorphismOptions.DerivedTypes
property on the JsonTypeInfo.PolymorphismOptions
property.
Note that while .NET 7 introduced polymorphic (de)serialization using
JsonDerivedType
attribute orJsonPolymorphismOptions
on a customIJsonTypeInfoResolver
implementation, Dapr does not ship a .NET 7 target of the SDK. Hence, a .NET 7 consumer application uses the .NET 6 target of the Dapr SDK. Therefore, this breaking change only applies when upgrading a consumer application to .NET 8.
Note that the new serialization behavior in the .NET 8 version of the SDK allows for polymorphic deserialization of the response by a weakly-typed actor client. This requires that the programmer specifies a
typeDiscriminator
on theJsonDerivedType
attribute.
This is the release candidate 1.13.0-rc.10
This is the release candidate 1.13.0-rc.9
This is the release candidate 1.13.0-rc.8
This is the release candidate 1.13.0-rc.7
This is the release candidate 1.13.0-rc.6
This is the release candidate 1.13.0-rc.5