This type of issue only applies for a block that contains inner blocks. There are flow(s) that try to enter an inner block when the block is neither active nor in state that can receive them.
It is important to know that token(s) moving through those flow(s) do not enter the inner block.
If an inner block should not receive token(s) at a particular state, then you can safely ignore this information. In fact, the contract of the inner block, in this case, protects the inner block.
An example of this case includes an event that can arrive before time, too late or doesn't arrive at all and an inner block that processes the event. When the event arrives too late, then a token indicating the event is stopped at the processing block.
However, if you do not intend to ignore the late incoming event, then you should change your specification. The animator can help you study the complete behavior of your specification.
You do not need to change anything necessarily. However, it is a good idea to check the behavior of your block with the animator. There might be behavior that you did not intend.
An example of this type of situation is depicted in the following figure.
In the upper part of the figure, we see while the inner block Processor is in state processing, a token flows from the rightmost timer, via operation /getInput/ and the merge node, and enters block Processor via pin in. As depicted in the contract on the left hand-side, only one activity step is allowed:
In another words, inner block Processor is not ready to receive an input via pin in when it is in state processing.
Here, the token that originates from the rightmost timer is stopped from entering the inner block via pin in.