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

Run check on automatic transitions on state change #114

Open
derkork opened this issue May 6, 2024 · 2 comments
Open

Run check on automatic transitions on state change #114

derkork opened this issue May 6, 2024 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@derkork
Copy link
Owner

derkork commented May 6, 2024

Currently automatic transitions will be evaluated whenever you enter a state, send an event or set an expression property. However we also have a guard that checks if a certain state is active and people are regularly confused about why the guard checking an expression property will be evaluated whenever we change an expression property, but the guard checking for a state being active is not checked when a state change happens.

The state charts "specification" is somewhat vague on when exactly automatic transitions are checked:

If a machine is in a state with a guarded automatic transition, then that guard is checked as often as possible. Being event driven, the guards are effectively only checked whenever an event has been processed, but also after other automatic transitions have fired, or other internal events (such as raised events) are fired

On one hand we have "as often as possible" which indicates we don't even need a trigger and should check them basically every frame, on the other hand there are specific occasions given.

If we lean more towards the former, then any change to the state of a state chart (actual states and expression properties) and the sending of any event would trigger the evaluation of automatic transitions.

@derkork derkork added the enhancement New feature or request label May 6, 2024
@derkork
Copy link
Owner Author

derkork commented May 6, 2024

This change will not be backwards compatible, so this needs to have some section in the manual and changelog. I also need some examples of flows that are broken by this change.

@derkork
Copy link
Owner Author

derkork commented Jun 6, 2024

This has proven to be extremely tricky. There are tons of edge cases where you end up in endless loops because any transition can trigger even more transitions. A particularly nasty example is:

image

Because A stays active all the time, it trigger a state enter/exit repeatedly which will again re-evaluate the transitions. A way to fix this would be to do it like this:

image

This way the DECIDE state would be left immediately after it has decided, thus breaking the loop because both transitions are no longer in play. But I really don't want the library to freeze if someone builds the problematic thing, especially since this thing is probably the first thing someone will come up with..

@derkork derkork added the help wanted Extra attention is needed label Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant