This type of issue indicates that there are flow(s) towards one or more output parameter nodes of the enclosing block, but there is no corresponding transition. It is important to know that token(s) moving through those flow(s) do not exit the enclosing block.
If token(s) should never exit an enclosing block at a particular state, then you can safely ignore the warning. In fact, the contract, in this case, protects the block.
For example, a block that waits for either a “SUCCESS” or a “FAILED” event. However, when a “SUCCESS” event happens, then “FAILED” event never occurs. Since at some state either event can arrive, then the two perceptions that correspond to both events each hold a token. When event “SUCCESS” arrives the token in the corresponding perception can flow out of the enclosing block. Meanwhile a token in the perception “FAILED” can still flow, but it may be stopped from flowing out of the enclosing block.
However, if you want the block still to be able to emit a “FAILED” event, then you should change your specification. The animation can help you to study the complete behavior of your block.
This situation is not an error. Thus, you do not required to change your block specification. However, it is a good idea to check the behavior of your block with the animation tool. There might be behavior that you did not intend.
An example of this type of situation is depicted in the following figure.
When block Sender is in state active, there can be a flow towards output parameter node failed from event FAILED. However, the contract of the block shown on the lower right hand-side shows that there are two transitions from state active:
Both transitions do not correspond to the mentioned flow.
In another words, after state active output failed is not possible. Here, the token that originates from event FAILED is stopped from leaving block Sender.