Using StrEnum for states with a HierarchicalMachine
induces unexpected behaviors.
#695
Labels
HierarchicalMachine
induces unexpected behaviors.
#695
Hi there, first of all I'd like to take this occasion to thank you for your awesome work with this lib. We use statecharts extensively at my company,
and this lib is a lifesaver. Been using it for years!
Describe the bug
Using StrEnum for states with a
HierarchicalMachine
induce the following unexpected behaviors at the moment:initial
parameter to set the initial state causes the code to crash when resolving the initial_stateget_transitions
does not include the expected transitions.These behaviors seem to be caused by
string_types
checks being applied beforeEnum
checks at several points.I listed the checks I've identified so far in "Additional Context"
Minimal working example
Expected behavior
I expect
StrEnum
to behave as normal Enum statesAdditional context
The root cause of these issues seems to be the order in which the
isinstance(<state_related_variable>, string_types)
andisinstance(<state_related_variable>, Enum)
areordered. At several places,
string_types
is checked first, and a member of a StrEnum is indeed as string types.So far, I have identified this pattern at the following places:
When setting up a scoping context, if
to_scope
is an Enum, it will go through the first, if,to_scope.split(self.state_cls.separator)[0]
will returnthe value of the enum member instead of the name, and the state lookup will fail (hence the
KeyError
)This happens during the recursive resolution of the initial_state. However, it does NOT happen when triggering an event, as build_state_tree use the state name,
which mean to_scope is always a string when resolving the trigger recursively in
_trigger_event_nested
In get_transitions
In the same fashion, when source is an enum, the source_path will be
[<enum member value>]
instead of the result of _get_enum_path because thestring_types
is matched firstIn add_states
And finally, when adding StrEnum states, the
_add_string_state
is used, which produces the wrong error message when using a separator in the name. This isthe only consequences here as far as I can tell
I've started to work on a PR to switch the order of the checks, I'll add it shortly after publishing this issue. Happy to hear your thoughts :)
Thanks again for maintaining this great project! 🎉
The text was updated successfully, but these errors were encountered: