Exclusive Join not working when embedded in Fork/Join
See original GitHub issueExclusive Join not working when embedded in Fork/Join
Problem
Hello,
In one of our workflows we have a very specific with the following (generic) flow: Note: the task types assigned to any TASK step(s) are not bound to any specific task type, this can be either a JOIN/FORK, LAMBDA, SIMPLE, etc… task type.
FORK(T1) -> |
TASK*(T2) -> |
DECISION(T2) -> TASK*(T3|T4) -> EXCLUSIVE JOIN(T5) -> |
JOIN(T6)
When we embed a decision with an exclusive join inside another fork/join, the workflow will not continue processing after the exclusive join and with that never completing the parent join. This only happens when we have the parent join (T6), join on the exclusive join (T5) (which is valid, see “Working alternative”).
Failing decision metadata representation:
{
"name" : "exclusive_join_test",
"description" : "Exclusive Join Test",
"version" : 1,
"tasks" : [
{
"taskReferenceName" : "fork",
"name" : "fork",
"forkTasks" : [
[
{
"name" : "lambda_nothing",
"taskReferenceName" : "lambda_nothing",
"inputParameters" : {
"scriptExpression" : "return {value: \"nothing\"}"
},
"type" : "LAMBDA",
"optional" : false,
"asyncComplete" : false
}
],
[
{
"name" : "decision_test",
"taskReferenceName" : "decision_test",
"inputParameters" : {
"case_value_param" : "${workflow.input.decision}"
},
"type" : "DECISION",
"caseValueParam" : "case_value_param",
"decisionCases" : {
"true" : [
{
"taskReferenceName" : "lambda_true",
"name" : "lambda_true",
"inputParameters" : {
"value" : "${workflow.input.decision}",
"scriptExpression" : "return {value: $.value}"
},
"optional" : false,
"type" : "LAMBDA",
"asyncComplete" : false
}
]
},
"defaultCase" : [
{
"name" : "lambda_false",
"taskReferenceName" : "lambda_false",
"inputParameters" : {
"value" : "${workflow.input.decision}",
"scriptExpression" : "return {value: $.value}"
},
"type" : "LAMBDA",
"optional" : false,
"asyncComplete" : false
}
],
"optional" : false,
"asyncComplete" : false
},
{
"name" : "exclusive_join",
"taskReferenceName" : "exclusive_join",
"type" : "EXCLUSIVE_JOIN",
"joinOn" : [
"lambda_true",
"lambda_false"
],
"optional" : false,
"defaultExclusiveJoinTask" : [
"decision_test"
],
"asyncComplete" : false
}
]
],
"type" : "FORK_JOIN"
},
{
"name" : "join",
"taskReferenceName" : "join",
"joinOn" : [
"lambda_nothing",
"exclusive_join"
],
"type" : "JOIN"
}
],
"inputParameters" : [
"decision"
],
"schemaVersion" : 2,
"restartable" : true,
"workflowStatusListenerEnabled" : false
}
Working alternative
However, when we isolate the same exclusive join outside of the fork/join, the exclusive join completes and the workflow continues as expected:
Working decision metadata representation:
{
"name" : "exclusive_join_test",
"description" : "Exclusive Join Test",
"version" : 1,
"tasks" : [
{
"name" : "decision_test",
"taskReferenceName" : "decision_test",
"inputParameters" : {
"case_value_param" : "${workflow.input.decision}"
},
"type" : "DECISION",
"caseValueParam" : "case_value_param",
"decisionCases" : {
"true" : [
{
"taskReferenceName" : "lambda_true",
"name" : "lambda_true",
"inputParameters" : {
"value" : "${workflow.input.decision}",
"scriptExpression" : "return {value: $.value}"
},
"optional" : false,
"type" : "LAMBDA",
"asyncComplete" : false
}
]
},
"defaultCase" : [
{
"name" : "lambda_false",
"taskReferenceName" : "lambda_false",
"inputParameters" : {
"value" : "${workflow.input.decision}",
"scriptExpression" : "return {value: $.value}"
},
"type" : "LAMBDA",
"optional" : false,
"asyncComplete" : false
}
],
"optional" : false,
"asyncComplete" : false
},
{
"name" : "exclusive_join",
"taskReferenceName" : "exclusive_join",
"type" : "EXCLUSIVE_JOIN",
"joinOn" : [
"lambda_true",
"lambda_false"
],
"optional" : false,
"defaultExclusiveJoinTask" : [
"decision_test"
],
"asyncComplete" : false
}
],
"inputParameters" : [
"decision"
],
"schemaVersion" : 2,
"restartable" : true,
"workflowStatusListenerEnabled" : false
}
Some metadata:
Conductor version: 2.10.2
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (2 by maintainers)
Thanks for reporting the issue. We will look into fixing this issue soon. However, feel free to submit a PR with the fix if you need this sooner.
Fixed as part of #1449