-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Workflow] Add options parameter to workflow start method #1120
Comments
My 2c public class ScheduleNewWorkflowOptions
{
// start time
public ReusePolicy ReusePolicy { get; set; }
// workflow tags
// etc.
}
public class ReusePolicy
{
public WorkflowState[] PermittedStates { get; set; }
public OnPolicyViolation PolicyViolationAction { get; set; }
}
public enum WorkflowState
{
Pending,
Running,
Completed,
Failed,
Paused,
Terminated
}
public enum PolicyViolationAction
{
Silent | Skip | Supress,
Throw
} The default behaviour when new ScheduleNewWorkflowOptions
{
ReusePolicy = new ReusePolicy
{
// No reuse, therefor maximum safety against accidentally rerunning a
// workflow and performing potentially duplicate / undesirable side-effects
PermittedStates = {},
// Maximum awareness to devs/operators that re-use is not occurring by
// throwing, they can choose to suppress if this is noisy
OnPolicyViolation = PolicyViolationAction.Throw
}
} The Exception thrown by
For daprWorkflowClient.ScheduleNewWorkflowAsync(
name : ...,
instanceId : ...,
options : new ScheduleNewWorkflowOptions {
reusePolicy : new ReusePolicy {
PermittedStates = { WorkflowState.Running, ... }
}}); This would permit an existing running/etc workflow to be replaced by another |
I like the idea of moving the options to an actual options class. Definitely allows for future growth without breaking changes. @olitomlinson proposal of a re-use policy also looks good. The only thing I'd change at this time is change the
By using enum flags the conditions can be merged and defaults can be included, such as an
The user can also use it in a fine grain manner by cherry picking specific conditions .
This one wouldn't allow re-use and would be the default condition.
|
As to the Adding it would close dapr/dapr#6450 |
Good suggestions, I'm onboard. |
I agree. Tucking the daprWorkflowClient.ScheduleNewWorkflowAsync(
name : ...,
instanceId : ...,
options : new ScheduleNewWorkflowOptions {
StartTimeUtc : DateTime.UtcNow().AddMinutes(5),
ReusePolicy : new ReusePolicy {
...
}
}); My only question here is at the point of performing the above operation, the runtime would have to 'claim' that particular Workflow ID (or not, and throw an exception etc) -- So what would the runtime status of the workflow be during the 5 minute window before the Workflow actually starts? |
Perhaps instead of As for the state I think the |
I'm not sure where I got the Probably also need a similar option for child workflows, or continue as new workflows. |
Describe the feature
This proposal applies to the
DaprWorkflowClient.ScheduleNewWorkflowAsync
method, which is specific to the Dapr Workflow engine. It doesn't apply toDaprClient.StartWorkflowAsync
, which is the "building block" API that is engine agnostic.The current signature looks like this:
However, it should ideally be changed to better align with Microsoft's Azure SDK guidelines for clients since those guidelines represent general best practices and many .NET developers will find them familiar.
Since this method could be considered complex, or could turn into a complex method, it should be changed to look something like this:
This should be done for the beta release since it's a breaking change and likely represents the path forward.
Release Note
RELEASE NOTE: UPDATE New (breaking) method signature for starting workflows
The text was updated successfully, but these errors were encountered: