Franz Steinmetz

@doem-an Yes, @franzlst is right can you reproduce by storing the state machine and doing this. Also it is of interest what is written in the log before this traceback...

I vote against it. Originally created by @sebastian-brunner ([email protected]) at 2019-02-04 13:32:46+00:00 (moved from RMC internal repository)

For a more differentiated and transparent implementation I also would extend the flag to be a dictionary tolerate_invalid with respective flags for any type of state element that is tolerated...

Can we discuss this in the next RAFCON meeting? Actually I do not like the concept that much. I will talk to Andreas and check his motivation again. Originally created...

I looked into the topic a bit deeper and as mentioned in the description the wrong data type is only one of the most common things. Here some more options...

Yeah let's discuss this in the meeting. I just saw that the LIBRARY_RECOVERY_MODE is not documented. Actually this is what I use to tackle these kind of problems. Originally created...

So checked the LIBRARY_RECOVERY_MODE flag and I have seen it while checking for this issue already and I could have investigate it more. 😄 The flag in its current implementation...

I have given it a shoot, see branch [allow_and_handle_invalid_elements_explicit](https://rmc-github-server/common/rafcon/tree/allow_and_handle_invalid_elements_explizit). * The handling for data flow and also transitions should be possible. * Corrections of io-data-ports should also result in data...

For data flows it works fine. Also the feature is nice, that the user can select the invalid data flow in the invalid elements list and the data flow becomes...

You are right have not tested it fully: * [x] have to adapt the parent assignment like for the data flow * [x] I have to improve the robustness of...