Open gastonfartek opened 3 months ago
This works as expected according to the SCXML semantics of conflicting transitions (see removeConflictingTransitions.
However, we have tweaked rules around reentrancy of source states (see here). Essentially, for many purposes we are using LCA over LCCA algorithms to detect "transitions containment". This makes this part of the mentioned removeConflictingTransitions
algorithm outdated for us:
Transitions that aren't contained within a single child force the state machine to leave the
ancestor (even if they reenter it later).
Our own implementation is still using our own computeExitSet
though so it could work correctly already - maybe there is a small bug there. I'm still trying to think through this case but it feels like - given the above - you are right that this should work.
Note though that:
on
in a final
state is forbidden by SCXML but it turns out that we don't quite enforce thisWe're going to look into this a bit more... may be a bug.
XState version
XState version 5
Description
Example:
on the state machine above I used to be able to send a
NEXT
event and it would togglevalue2
on the first call andvalue3
on the second call, however since upgrading to v5 only theNEXT
fromvalue1
is being called, is this expected behavior now?Here is a codesandbox with this machine and xstate v5
Here is a codesandbox for xstate V4
Expected result
it should call
NEXT
on value2.shownActual result
only
NEXT
from value1 is ever triggeredReproduction
https://codesandbox.io/p/sandbox/test-xstate-4xcj29?file=%2Fsrc%2FApp.js%3A10%2C14
Additional context
No response