I noticed in entryToState method in AbstractStateMachine class. It will use stateContext build from the input parameter "transition" and feed it to state.entry(). And when it notifies "external" listeners with "notifyStateEntered" method, it builds a stateContext with the "state" from input parameter as target state. Usually, it is not a problem as transition.getTarget equals to the input parameter "state".
However, for "withChoice", they are different. The input parameter "state" is a correct target state based on guards. The transition.getTarget() is a target state of previous transition(or the source of the current one). In this case, the external listeners for StateEnter will get a correct target state, while the internal stateEntry action will get a state of the current source state.
I can see pseudo state lives on top of a real transition. That is why the transition is carrying over. But, inconsistency of target state in the above two stateEntry handling feeling weird.
I noticed in entryToState method in AbstractStateMachine class. It will use stateContext build from the input parameter "transition" and feed it to state.entry(). And when it notifies "external" listeners with "notifyStateEntered" method, it builds a stateContext with the "state" from input parameter as target state. Usually, it is not a problem as transition.getTarget equals to the input parameter "state". However, for "withChoice", they are different. The input parameter "state" is a correct target state based on guards. The transition.getTarget() is a target state of previous transition(or the source of the current one). In this case, the external listeners for StateEnter will get a correct target state, while the internal stateEntry action will get a state of the current source state.
I can see pseudo state lives on top of a real transition. That is why the transition is carrying over. But, inconsistency of target state in the above two stateEntry handling feeling weird.