Hide Forgot
Description of problem: When having a dependent process that does not have to wait for completion and the parent process is aborted, the subprocess is still in active state. Version-Release number of selected component (if applicable): BRMS-5.3.0-ER3 How reproducible: Every time Steps to Reproduce: 1. start process with subprocess (dependent, no wait for completion) 2. abort parent process 3. get subprocess state Actual results: STATE_ACTIVE Expected results: STATE_ABORTED Additional info: Pull request will follow shortly
Pull request #52 was submitted
It is correct that abortion of dependent sub-processes only works if waitForCompletion is set to true. I'm wondering if we should just document this (as it seems reasonable to assume that you want to keep track of whether it is completed or not if you want to abort it if necessary), or whether we should attempt to implement it anyway. My suggestion would be to document it, as it would keep the code simpler, and we already offer a workaround that is almost identical, where you could use a parallel gateway before the sub-process, if you want to trigger rest of the path (not wait for completion) while also supporting aborting as a dependent sub-process.
Documentation says: "Independent: If this property is true, ... ; otherwise the active sub-process will be cancelled on termination of the parent process (or cancellation of the sub-process node)." It doesn't say anything about cancelling only processes that are waited for. IMHO the sub-process that is dependent should be cancelled even if it is not waited for. If you need an example: a long term process starts recurring sub-process (therefore it is not waited for it to complete) that should only run as long as the starting process lasts. The workaround you speak of is a possible solution, but it is just a workaround.
I just found out a new problem in this - the subprocess is aborted (beforeNodeCompleted event is fired saying that state of process instance is STATE_ABORTED). The real problem is that the subprocess was waiting for a signal and when the event was signalled, the subprocess (that was already supposed to be aborted) fired beforeProcessCompleted with STATE_COMPLETED.
This has been updated in the community docs, you should only use dependent set to "false" if "wait for completion" is set to "true".
This is already in BRMS BPM user guide, therefore marking the bug as verified.