search

dapr / dapr

Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
https://dapr.io
Apache License 2.0
24.18k stars 1.91k forks source link

[Tracking issue] Dapr Workflows Stable #8008

Open olitomlinson opened 3 months ago

olitomlinson commented 3 months ago

This issue will be the source of truth for collating all tasks what must be complete in order for Workflows to progress to Stable, for the 1.15 release.

Dapr Runtime / durabletask-go

Contrib / State Store

Quickstarts

Perf

Docs

SDKs

.NET SDK

Java SDK

JavaScript SDK / durabletask_js - thank you @famarting

Go SDK - thank you @famarting

Python SDK - thank you @famarting

Deferred / Not essential for Stable

arturotrenard commented 2 months ago

Hello, this keeps happening. https://github.com/dapr/dapr/issues/7824 @olitomlinson

mikeee commented 2 months ago

@dapr/approvers-dotnet-sdk @dapr/maintainers-dotnet-sdk - Are all of these SDK issues proportionate, necessary, appropriate and is there bandwidth to get them completed for workflows to be stable?

olitomlinson commented 2 months ago

@mikeee I wasn't clear btw, I fully expect the above list to be triaged for suitability by the maintainers for what is in and out of scope for 1.15 :)

mikeee commented 2 months ago

@mikeee I wasn't clear btw, I fully expect the above list to be triaged for suitability by the maintainers for what is in and out of scope for 1.15 :)

Thought so, I'll await the dotnet-sdk maintainers to triage the SDK items

cgillum commented 2 months ago

I'll be helping out with the triage of these items over the next few days.

cgillum commented 2 months ago

@olitomlinson I think https://github.com/dapr/dapr/issues/3417 might be referring to GitHub actions workflows and not Dapr Workflow. If you agree, then we can probably take it off this list.

cicoyle commented 2 months ago

I went ahead and added [P_] next to the above issues for us to better see what work is a P0 for this release

olitomlinson commented 2 months ago

@cgillum this should probably go on the list too right? (And fixes for all other language SDKS)

https://github.com/dapr/dapr/issues/7218 / https://github.com/dapr/dotnet-sdk/pull/1244

famarting commented 1 month ago

@olitomlinson @cgillum I'll be going through the go, python and javascript SDKs to review the different changes we need pursuing SDK parity and workflows to become stable

So far this is a list of issue for the go sdk that I believe should be tracked here:

Oli : Moved items into main post

famarting commented 1 month ago

Here are the issues for the python SDK, notice the issues that are closed should be re-opened

Oli : Moved items into main post

famarting commented 1 month ago

And the js sdk issues, the durabletask-js issues would need their counterpart issues created in the js-sdk repo:

Oli : Moved items into main post

WhitWaldo commented 1 month ago

@olitomlinson The top P0 item in the .NET SDK referencing https://github.com/dapr/dotnet-sdk/issues/1344 can be marked off as completed.

So can the P0 item referencing an Unknown status referencing https://github.com/dapr/dotnet-sdk/issues/1215

cgillum commented 1 month ago

Added prioritized list of Java SDK issues to the OP.

WhitWaldo commented 1 month ago

@olitomlinson I'd like to propose adding https://github.com/dapr/dapr/issues/7321 to the stabilization list as it's a named issue on the Workflow Limitations, but the issue was closed due to staleness.

olitomlinson commented 1 month ago

I've discovered that the workflow SDKs are inconsistent in the naming of callChildWorkflow / callSubWorkflow

I believe the SDKs should strive for consistency where sensible, and should strive to be consistent with the docs which only refers to child workflows

I've raised tickets to bring the Java and JS SDKs inline with the others :

I believe these would both be considered P0 as we want to go into the Stable release with method names that won't change.

Thoughts @yaron2 @artursouza ?

olitomlinson commented 1 month ago

@olitomlinson I'd like to propose adding #7321 to the stabilization list as it's a named issue on the Workflow Limitations, but the issue was closed due to staleness.

I agree. I've reopened this and added this to the main list.

@cgillum what priority should be attached to this item? Are we intending to ship with CosmosDb support in 1.15?

cgillum commented 1 month ago

@olitomlinson per an earlier discussion with @yaron2, I think the best path forward is to have a list of supported state stores for workflow, similar to actors (it would necessarily be a subset of actor state stores). Cosmos DB and similar state stores would not be on that list due to the issue you linked to. Unfortunately, I think there isn't enough time to work through those issues before Stable.

WhitWaldo commented 1 month ago

@cgillum Is there an issue somewhere that tracks progress of the NoSQL support and what's lacking?

cgillum commented 1 month ago

@WhitWaldo I don't believe we have an issue tracking progress of this work. However, I do have an old PR that does the foundational work in the durabletask-go dependency to enable it: https://github.com/microsoft/durabletask-go/pull/50 ("state update chunking"). The main problem has been finding the time to validate and stabilize it.