feat!: unify the durable task client into dapr-sdk-workflows - #1800
Open
javier-aliaga wants to merge 6 commits into
Open
feat!: unify the durable task client into dapr-sdk-workflows#1800javier-aliaga wants to merge 6 commits into
javier-aliaga wants to merge 6 commits into
Conversation
The durabletask-client module duplicated much of the workflows API across a module boundary, which forced an adapter layer and a second copy of a dozen types. Fold it into dapr-sdk-workflows and remove it. The absorbed types move from io.dapr.durabletask.* to io.dapr.workflows.task.*, split into client, worker, history, exception, serialization and internal subpackages. Twelve duplicate type-pairs collapse to one each. Most significantly TaskOrchestrationContext becomes WorkflowContext and is implemented directly by the replay executor, so the DefaultWorkflowContext adapter and the converter and wrapper classes it required are gone. Two behaviour changes come with the merge: - The runtime's default executor is a virtual-thread-per-task executor on Java 21+, resolved reflectively so the module still compiles at release 17 and never names a Java 21 API. WorkflowRuntime now tracks whether it created the executor and no longer shuts down one supplied by the caller, so handing it a framework-managed executor is safe. - WorkflowRuntimeStatus absorbs the protobuf mapping and gains STALLED, which the deleted converter rejected with an exception. isCausedBy maps the exception names that shipped under io.dapr.durabletask onto their current types, so a workflow started before the upgrade still resolves its failure type after it. The CI job that built durabletask-client now installs its reactor dependencies first: unlike the old module, the merged one depends on the sibling dapr-sdk and cannot be built standalone. BREAKING CHANGE: io.dapr:durabletask-client is removed and its classes ship in io.dapr:dapr-sdk-workflows. Types move from io.dapr.durabletask.* to io.dapr.workflows.task.*, seven types are renamed, and the four @deprecated(forRemoval) DaprWorkflowClient methods together with WorkflowInstanceStatus are removed. See MIGRATION.md for the full type mapping and for what it means for workflows that are already running. Signed-off-by: Javier Aliaga <javier@diagrid.io>
Folding durabletask-client into dapr-sdk-workflows is a breaking change, so document it where an upgrader will look: MIGRATION.md carries the full old-to-new type mapping, the renames, the removed API, the behaviour changes that are invisible to the compiler, and a tested rewrite script for the mechanical import changes. The section on workflows that are already running is the important one. The error type is persisted into workflow history, so a workflow started before the upgrade carries the old exception names; the guide explains what the SDK maps for you and what it does not. Link the guide from README.md and SUPPORT.md, drop durabletask-client from the module lists in both, and record that Java 21 is recommended for workflows now that the default executor uses virtual threads there. Signed-off-by: Javier Aliaga <javier@diagrid.io>
…private Splitting the folded durable task types into subpackages moved the executor away from the exceptions it constructs, and the visibility was widened to compensate. It was widened further than the split required: every constructor on both classes became public where only the two the executor actually calls needed to be. Restore the rest to package-private, matching what they were before the merge. The two that stay public are the ones the executor constructs from io.dapr.workflows.task.internal, and their javadoc now says so accurately — the previous note claimed a sibling-package caller for members that have none. No test used any of these constructors, and no behaviour changes. Signed-off-by: Javier Aliaga <javier@diagrid.io>
The runtime defaults to a virtual-thread-per-task executor on Java 21+, which existing deployments get without changing any code. That is the right default — activities run user code and typically block on I/O — but it is not right for everyone: activity code that holds a monitor across a blocking call pins a carrier thread on Java 21 through 23. Add dapr.workflows.virtual.threads.enabled (env DAPR_WORKFLOWS_VIRTUAL_THREADS_ENABLED), default true, following the existing workflow property convention. Setting it false keeps the cached thread pool used on earlier runtimes. It only affects the executor the runtime creates for itself, so it has no bearing on Java 17 through 20 or on a runtime handed an executor via withExecutorService. Document the opt-out in SUPPORT.md and MIGRATION.md, and correct a claim in SUPPORT.md that spring.threads.virtual.enabled reaches the workflow runtime: it switches Spring's own executors, but the Dapr auto-configuration does not pass the application's task executor to WorkflowRuntimeBuilder, so workflow execution is unaffected by it. Signed-off-by: Javier Aliaga <javier@diagrid.io>
javier-aliaga
changed the title
javier-aliaga
marked this pull request as ready for review
September 1, 2026 11:36
…ronment The workflow runtime resolves dapr.workflows.virtual.threads.enabled through the SDK Properties, which consults only JVM system properties and environment variables. Setting it in application.properties silently did nothing, because the auto-configuration builds its property overrides from the connection details alone. The auto-configured WorkflowRuntimeBuilder now layers the Spring Environment over those overrides, so the opt-out works like any other Spring property. When the property is set nowhere no override is added and the SDK default still applies. spring.threads.virtual.enabled remains unrelated to the workflow runtime: Spring's virtual-thread applicationTaskExecutor is a SimpleAsyncTaskExecutor, which is not an ExecutorService and cannot be handed to withExecutorService without an adapter. SUPPORT.md is corrected to say so, and to drop the advice to define a custom builder bean, which is unnecessary now that virtual threads are the default on Java 21. Signed-off-by: Javier Aliaga <javier@diagrid.io>
State in SUPPORT.md that durabletask-client is folded into dapr-sdk-workflows in 1.19.x, so a user reading the version table knows which upgrade requires the source changes described in MIGRATION.md. Signed-off-by: Javier Aliaga <javier@diagrid.io>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1800 +/- ##
============================================
- Coverage 77.10% 70.91% -6.20%
- Complexity 2317 2490 +173
============================================
Files 245 277 +32
Lines 7186 9105 +1919
Branches 750 1012 +262
============================================
+ Hits 5541 6457 +916
- Misses 1284 2170 +886
- Partials 361 478 +117 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
durabletask-clientis now part ofdapr-sdk-workflowsand no longer ships as a separate artifact. Its classes move fromio.dapr.durabletask.*toio.dapr.workflows.task.*. Twelve duplicated types are reduced to one copy each, which removes the adapter layer that sat between the two modules. Seven types are renamed. Four@Deprecated(forRemoval)methods onDaprWorkflowClientand theWorkflowInstanceStatustype are removed.Two behaviour changes. The runtime now uses a virtual-thread-per-task executor on Java 21 and later; set
dapr.workflows.virtual.threads.enabledtofalseto opt out.WorkflowRuntimeno longer shuts down an executor supplied by the caller.This is a breaking change for workflow code.
MIGRATION.mdhas the type mapping, the removed API, and what happens to workflows that are already running during an upgrade.Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list: