Re: Requesting guidance on scxml-irp test236.txml

Yes, I see this now in the pseudocode of exitInterpreter. Thank you, Jim.

> On Jul 5, 2017, at 11:14 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:
> 
> The final state in question is a child of <scxml>, and section 3.7.2 says "When the state machine reaches the <final> child of an <scxml> element, it MUST terminate."  That holds whether the session has been invoked or not.  Now it's bit sloppy that the prose doesn't state that this involves executing the <onexit> handler of the <final> state, but in the pseudo-code the  procedure exitInterpreter shows this happening:
> 
> procedure exitInterpreter():
>     statesToExit = configuration.toList().sort(exitOrder)
>     for s in statesToExit:
>         for content in s.onexit.sort(documentOrder):
>             executeContent(content)
>         for inv in s.invoke:
>             cancelInvoke(inv)
>         configuration.delete(s)
>         if isFinalState(s) and isScxmlElement(s.parent):   
>             returnDoneEvent(s.donedata)
> 
> Does this answer your question?
> 
>  - Jim
> 
> 
> On 7/5/2017 10:49 AM, Jacob Beard wrote:
>> Hello,
>> 
>> In the SCXML IRP test236.txml, there is a final state that contains an <onexit> action:
>> 
>> <final id="subFinal">
>>   <onexit>
>>     <send target="#_parent" event="childToParent"/>
>>   </onexit>
>> </final>
>> 
>> https://www.w3.org/Voice/2013/scxml-irp/236/test236.txml <https://www.w3.org/Voice/2013/scxml-irp/236/test236.txml>
>> 
>> 
>> 
>> In test236, it appears that the invoked session is not cancelled, as state s0 is not exited before the invoking session receives the done.invoke.id event. My question is, how can the onexit handler in state subFinal fire under this scenario?
>> 
>> My main assumption is that the only method to trigger the exit handler of a final state is to cancel the invoked session. This is described in the spec:
>> 
>> ... if the invoking state machine exits the state containing the invocation before it receives the done.invoke.id event, it cancels the invoked session. The method for doing this is platform-specific. However, when it is cancelled, the invoked session must exit at the end of the next microstep. The Processor must execute the <onexit> handlers for all active states in the invoked session, but it must not generate the done.invoke.id event. Once it cancels the invoked session, the Processor must ignore any events it receives from that session. In particular it must not not insert them into the external event queue of the invoking session.
>> 
>> 
>> To cancel the invoked session, the invoking session must take a transition out of the state containing the <invoke> before the invoking session receives the done.invoke.id event, as described in the spec:
>> 
>> If the invoking session takes a transition out of the state containing the <invoke> before it receives the 'done.invoke.id' event, the SCXML Processor must automatically cancel the invoked component and stop its processing. The cancel operation must act as if it were the final <onexit> handler in the invoking state.
>> 
>> 
>> 
>> In test236, it appears that the invoked session is not cancelled, as state s0 is not exited before the invoking session receives the done.invoke.id event, therefore the onexit handler of state subFinal should not fire. Is there a way for the onexit handler of a final state to fire, other than by canceling the invoked session?
>> 
>> I would appreciate your guidance on the expected behavior of this test case. Thank you for looking into this,
>> 
>> Jacob Beard
>