Consider something like this:
The timer is a Cycle timer such as R/PT5H
When the message is received, I would expect based on the way docs are written (from what i have found) that a Timer should stop executing, but any user tasks that are still active would be allowed to be completed. I would assume this because the Event Sub Process Start Event is tied to the parent process. But the event sub process is also its own execution.
So if the parent process is no longer active, why does the timer continue to execute?
Additionally, if you were to complete the user task before the next execution of the timer, then the timer stops. So it seems that because there are active user tasks, the timer’s execution continues…
cc @thorben
ref:
additional ref: Pattern Feedback: Timer Cycle Checking of external systems State/Status
1 Like
Is this not expected behaviour? The execution of spawned event sub processes must be completed before the execution they belong to (their scope) is also completed.
@tiesebarrell the docs on how event sub processes work seem to indicate otherwise:
The subscription to the start event is created when the scope (process instance or subprocess) hosting the event subprocess is created. The subscription is removed when the scope is ended.
Followed by
When an event subprocess is ended, either the current scope is ended (in case of an interrupting event subprocess), or the concurrent execution spawned for the non-interrupting subprocess is ended.
From the first quote, the “scope” is the scope of the parent process. the non interrupting start event of the event sub process creates a additional execution of the parent process id. So when the parent scope has wended the subscription to the timer should have ended as well (based on the docs and what would seem very logical and intuitive)
I see what you mean here, but wasn’t your point that the execution was not ended because of pending user tasks? That seems still in line with those descriptions. The subscription for the timer is removed, so no new instances of the event sub process are started, but any ones still active must be completed still, which is the case if there’s still a user task pending.
So no, the subscription is only removed once all active user tasks are completed.
New executions of the timer continue to fire even after the parent scope has completed (parent process). The user tasks in the sub process execution are keeping the subscription alive, even when it should have been removed
1 Like
Aha, now I see where you’re seeing strange behaviour. That seems like unintended from what you’d expect.
1 Like
We have confirmed that this occurs at least all the way back to 7.8.
I can see it be easily missed, as you would likely unit test something like a script or service task which would complete before the next execution of the timer.
Indeed, easily missed that way. Still, a very valid case for periodic escalation.
A common scenario I see this pattern occur in is creating recurring task definitions: “start a process with some configuration variables, which configured the timer in the event sub process. When you want to stop the recurring task then you message the parent process to stop”
It would be interesting to know if this also happens if you would use a sub process containing the event sub process and used a message boundary event to cancel the sub process. 
