docs/release_notes/v1.13.0.md
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 7176priorityClass in Helm charts 7103 7395dapr_sidecar_injector.enableK8sDownwardAPIs to improve detection of pod IP in certain Kubernetes environments 7511--dapr-block-shutdown-duration to daprd 7268 4313grpc_server_status label missing for gRPC server latency metric 7045 7255deploymentAnnotations produces invalid Helm chart 7194RenameReminder methods 6711 6945AppChannelAllowInsecureTLS feature flag, and require TLS-enabled app channel to use TLS 1.2+ 7292 7149content-length metadata in pubsub subscription. 7413 7421Dapr 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 3122disableEntityManagement metadata option to work with minimal Microsoft Entra ID permissions 3213EnableHostVerification 3230~/.dapr given 777 permissions. 1317wait 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 958To 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#6711AppChannelAllowInsecureTLS 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#7149INVALID_ARGUMENT, FAILED_PRECONDITION) instead of the generic UNKNOWNAdditional 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
JsonDerivedTypeattribute orJsonPolymorphismOptionson a customIJsonTypeInfoResolverimplementation, 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
typeDiscriminatoron theJsonDerivedTypeattribute.