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] The workflow is un-deterministic when there a many transition with the same name #29140

Closed
lyrixx opened this Issue Nov 8, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@lyrixx
Member

lyrixx commented Nov 8, 2018

When many transitions have the same name, the workflow because un-deterministic. This is not cool.
It's impossible to build something really strong. How could the workflow guess what the dev intent?

I propose to update the interface:

- can(object $subject, string $transitionName)
+can(object $subject, Transition $transition)
- apply(object $subject, string $transitionName)
+apply(object $subject, Transition $transition)

I will add some helper to get the best transition for a transition name.

This will fix :

@lyrixx

This comment has been minimized.

Member

lyrixx commented Nov 8, 2018

Or another fix could be to forbid the use of the same transition name.
I order to address the use case:

For example I regularly use an update transition for almost all states which does not change the state at all. If the same name must not exist mutliple times I would need to name them updatewaiting, updateapproved, etc. which seems clumsy

User could easilly leverage metadata

What do you think ?

Note: I think I prefer the last option because it's much more simple, the BC layer will be much more easier to achieve, and there will be less code

@stof

This comment has been minimized.

Member

stof commented Nov 8, 2018

Well, for a full-featured workflow, I think we already enforce transition name uniqueness.
For a state machine, we enforce uniqueness of transition names among transitions with the same starting point. Given the constraints put on state machines (the marking contains a single state, and transition have a single starting and ending state), this should not lead to any non-determinism.

If there are issues currently, they are not due to inherent non-determinism, but to implementation bugs (as the initial implementation had unique transition names, we may still have some code relying on this gone assumption)

@lyrixx

This comment has been minimized.

Member

lyrixx commented Nov 8, 2018

Well, for a full-featured workflow, I think we already enforce transition name uniqueness.

nope

For a state machine, we enforce uniqueness of transition names among transitions with the same starting point.

yes.

If there are issues currently, they are not due to inherent non-determinism, but to implementation bugs

Yes, may be ;) I'm trying to solve them ATM ;)

@lyrixx

This comment has been minimized.

Member

lyrixx commented Nov 8, 2018

Closing this issue are @stof is right (but still, the code is much more complicated now :( )

@lyrixx lyrixx closed this Nov 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment