Skip to content
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

fix(*): parallelState with completeType defaults to allOf #106

Merged
merged 1 commit into from
Oct 24, 2022
Merged

fix(*): parallelState with completeType defaults to allOf #106

merged 1 commit into from
Oct 24, 2022

Conversation

lsytj0413
Copy link
Collaborator

@lsytj0413 lsytj0413 commented Oct 13, 2022

Signed-off-by: lsytj0413 511121939@qq.com

Many thanks for submitting your Pull Request ❤️!

What this PR does / why we need it:

  • set ParallelState.CompleteType defaults to allOf
  • add validate for ParallelState.NumCompleted

Special notes for reviewers:

Additional information (if needed):

Fixed #108


// Used when completionType is set to 'atLeast' to specify the minimum number of branches that must complete before the state will transition."
// TODO: change this field to unmarshal result as int
NumCompleted intstr.IntOrString `json:"numCompleted,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember why I made this IntOrString, it seems that it should be int only.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Because the specification defines the field as number or string. Maybe we should change the specification to simplify it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a possibility.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we merge this PR first?because the implement is base on v0.8 specification.
And i will open an Issue to change the specification.

Copy link
Member

@spolti spolti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before merge, can we wait for #104 ?

@spolti
Copy link
Member

spolti commented Oct 13, 2022

I would like to made a suggestion to avoid us to possibly work on the same part without knowing until the PR is open.
Would be nice then, to open a issue before work on a improvement or bug fixing, that way, it will allow us to know what needs to be done and to who the task is assigned, avoiding the issue I mentioned above. wdyt?

@lsytj0413
Copy link
Collaborator Author

I would like to made a suggestion to avoid us to possibly work on the same part without knowing until the PR is open. Would be nice then, to open a issue before work on a improvement or bug fixing, that way, it will allow us to know what needs to be done and to who the task is assigned, avoiding the issue I mentioned above. wdyt?

Good point, i will open an issue for this PR.

Before merge, can we wait for #104 ?

Yep, we can merge 104 first.

Signed-off-by: lsytj0413 <511121939@qq.com>
@lsytj0413
Copy link
Collaborator Author

@spolti @ricardozanini I have resolved the conflict, PTAL

@ricardozanini ricardozanini merged commit 85c2f4d into serverlessworkflow:main Oct 24, 2022
@lsytj0413 lsytj0413 deleted the split-parallel-state branch October 24, 2022 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Set ParallelState.CompleteType defaults to allOf
3 participants