Terminate end event does not terminate process when waiting at parallel gateway #10590
Assignees
Labels
area/reliability
Marks an issue as related to improving the reliability of our software (i.e. it behaves as expected)
kind/bug
Categorizes an issue or PR as a bug
scope/broker
Marks an issue or PR to appear in the broker section of the changelog
severity/mid
Marks a bug as having a noticeable impact but with a known workaround
version:8.1.3
Marks an issue as being completely or in parts released in 8.1.3
version:8.2.0-alpha2
Marks an issue as being completely or in parts released in 8.2.0-alpha2
version:8.2.0
Marks an issue as being completely or in parts released in 8.2.0
Comments
remcowesterhoud
added
kind/bug
10 tasks
|
The problem here is quite straightforward. The flow scope in which the end event exists still has one active sequence flow. Upon completing this end event we check if this is the end of the execution path. Since this is the case we will see if there is any active element instances or active sequence flows left. If that is not the case the flow scope will be completed. Since there is 1 active sequence flow the flow scope will not be completed. |
10 tasks
korthout
added
the
version:8.1.3
zeebe-bors-camunda bot
added a commit
that referenced
this issue
Nov 22, 2022
10595: Add terminate end event to randomised tests r=remcowesterhoud a=remcowesterhoud ## Description <!-- Please explain the changes you made here. --> This PR will generate processes containing terminate end events. When a terminate end event is reached the flow scope should be terminated (not that it writes a COMPLETED event for the flow scope itself). If this was the root flow scope the process is completed, otherwise processing will continue as expected. At this moment this PR only adds terminate end events through boundary events on user tasks, job worker tasks, and sub processes. Just this allows the events to be present in different flow scopes of the process. Since the randomised tests don't know the concept of flow scopes it's not straightforward to support terminate end events. Generating them is easy, however having to generate an execution path proofs difficult. What we do have is `ExecutionPathSegements`. An `ExecutionPathSegment` is a set of steps that completes a specific part of the process. To understand this PR it is required to know how the execution path generation works. A randomly generated process consist of `BlockBuilders`. Each `BlockBuilder` is responsible for generating a part of the process. There is many different kinds of `BlockBuilders`, for example `UserTaskBlockBuilder` and `SubProcessBlockBuilder`. When we generate an execution path we will iterate over these `BlockBuilders` and each of them will generate it's own `ExecutionPathSegment`. These `BlockBuilders` are nested. We always have a root `BlockSequenceBuilder`. Generating an execution path causes this root `BlockBuilder` to iterate over all the `BlockBuilders` nested within it. For each of these it will generate the execution path and append the execution steps of that segment to it's own `ExecutionPathSegment`. Of course generating the path for this nested block builder will result in the nested block builder generating that are nested within that block builder as well. By doing this the root block builder will end up with an `ExecutionPathSegment` which contains all the execution steps for the entire process. The tricky part for this PR is that we somehow need to stop appending new execution paths to the `ExecutionPathSegment` when we encounter a terminate end event. For this I've introduced a boolean on the `ExecutionPathSegment`. Because of this flag each `BlockBuilder` will have the freedom to decide what should happen when a terminate end event is reached. Some will prevent the appending of new segments (e.g. `ExclusiveGatewayBlockBuilder`), and some will allow appending new segments after the current (e.g. `SubProcessBlockBuilder`). As mentioned I've only introduces the terminate end event connected to boundary events. The reasoning for this is that the randomised tests are already complex as-is. There is no straightforward way to have 1 branch of a gateway connect to a terminate end event. Since the boundary events already cover all scenarios I believe it is fine to limit it to this. ## Related issues <!-- Which issues are closed by this PR or are related --> blocked by #10590 closes #10476 11067: docs(docker): hint on BuildKit being required r=megglos a=megglos ## Description As found yesterday the recent changes to the Dockerfile introducing the TARGETARCH var require Docker BuildKit to be enabled. Co-authored-by: Remco Westerhoud <remco@westerhoud.nl> Co-authored-by: Meggle (Sebastian Bathke) <sebastian.bathke@camunda.com>
remcowesterhoud
added
the
version:8.2.0-alpha2
npepinpe
added
the
version:8.2.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When a process instance is waiting at a parallel gateway to resume, and while waiting a terminate end event is triggered the process instance does not get completed as expected.
To Reproduce
Unit test
Expected behavior
Log/Stacktrace
Full Stacktrace
Environment:
The text was updated successfully, but these errors were encountered: