flexbe_behavior_engine
flexbe_behavior_engine copied to clipboard
Problem with same named states from different packages
Hi,
I noticed an issue with states imports when having same named states in different packages. For example if I have a state named SetParameter in the package named package1_states, the import would look something like this:
from package1_states.set_parameter import SetParameter
Then I created a second package named package2_states with the included state named SetParameter and when I opened a previously stored behavior that uses SetParameter state from package1_states and stored it again, it changed to this:
from package2_states.set_parameter import SetParameter as package2_states__SetParameter
.
That means that the import has been made from the wrong package.
My suggestion is that probably it would be good to always write a package name beside the imported state so it would not mess up old behaviors when a new package appears with same named states but anyway something is wrong with the code generation as from the original import it is already known from which package it was taken and the generator shouldn't then take it from somewhere else.
Best regards, F
Thanks for reporting!
First, note that there is a configuration field called "Explicit state package" in the FlexBE App Configuration panel to always specify the package as you described.
Anyways, I can reproduce the behavior as you describe it. The code parser is indeed understanding the correct package from the import, however, the package information is not correctly propagated to the actual usage of the state within the statemachine, that's why a wrong connection is made in the end. I will see how to fix this.
Should be fixed by the above commit.
Hi Philipp,
thanks for the fix!
There is a similar issue but in this case with behaviors:
Behavior "Polymorphism" almost working but behavior list points to same package.
Maybe you have a hint?
Cheers!
Thanks for the pointer @romayiii! Yes, I saw this issue and already had a look at the reason. It is, unfortunately, not as easy to address as the issue here, but I agree that it needs to be fixed as one of the next tasks regarding the app.