Writing a DecisionEvaluationResult fails because EvaluatedInput.inputName() is null
#8909
Assignees
Labels
kind/bug
Categorizes an issue or PR as a bug
Comments
|
@korthout - could we have a look at this and see if this is a quick fix for 1.4? |
korthout
added a commit
that referenced
this issue
Mar 15, 2022
The decision engine can evaluate decisions where the inputs and outputs of a decision table don't have names (or labels). In that case the name property is null. We can't write null in records, instead we should write an empty string "". See #8909
10 tasks
|
Thanks for reporting @oleschoenburg. I think this is a bug. Alternatively, it could have been a case where we simply want to add a deployment validator, but I think we want to support this case. I've created a fix for it, but I'm keeping it in draft until I've confirmed that we consider this a valid decision model. |
|
As far as I can tell, this is indeed a bug. For inputs, the spec does not define names. Labels can be attached but are optional. We use the label as a way to display names for inputs in the modeler. Naming inputs is something Camunda does but is not officially part of the DMN spec. For outputs, names are part of the DMN spec. They are only mandatory for decision tables with multiple outputs. So single output decision tables can leave out the output name. So in my opinion, the case above is a bug and it is fixed by allowing inputs and outputs without names (or labels). I'll mark the PR as ready for review. |
korthout
added a commit
that referenced
this issue
Mar 21, 2022
The decision engine can evaluate decisions where the inputs and outputs of a decision table don't have names (or labels). In that case the name property is null. We can't write null in records, instead we should write an empty string "". See #8909
ghost
pushed a commit
that referenced
this issue
Mar 21, 2022
8919: Support decision table inputs and outputs without names/labels r=korthout a=korthout ## Description <!-- Please explain the changes you made here. --> A decision tables' inputs and outputs must have an id and can have a name. The name (or label) is not mandatory. Even though the internal decision engine was already able to deal with this, the workflow engine wasn't. It would try to write the EvaluationEvent record with an EvaluatedInputRecord (or EvaluatedOutputRecord) and then fail writing it because of a NullPointerException. This makes sure these records can be written when the name of the input or output is undefined. ## Related issues <!-- Which issues are closed by this PR or are related --> closes #8909 Co-authored-by: Nico Korthout <nico.korthout@camunda.com>
ghost
pushed a commit
that referenced
this issue
Mar 21, 2022
8919: Support decision table inputs and outputs without names/labels r=korthout a=korthout ## Description <!-- Please explain the changes you made here. --> A decision tables' inputs and outputs must have an id and can have a name. The name (or label) is not mandatory. Even though the internal decision engine was already able to deal with this, the workflow engine wasn't. It would try to write the EvaluationEvent record with an EvaluatedInputRecord (or EvaluatedOutputRecord) and then fail writing it because of a NullPointerException. This makes sure these records can be written when the name of the input or output is undefined. ## Related issues <!-- Which issues are closed by this PR or are related --> closes #8909 8939: refactor: use foreign keys for decisions r=oleschoenburg a=oleschoenburg ## Description Uses `DbForeignKey` internally to maintain referential integrity within `DbDecisionState` relates to #8930 Co-authored-by: Nico Korthout <nico.korthout@camunda.com> Co-authored-by: Ole Schönburg <ole.schoenburg@gmail.com>
ghost
pushed a commit
that referenced
this issue
Mar 21, 2022
8919: Support decision table inputs and outputs without names/labels r=korthout a=korthout ## Description <!-- Please explain the changes you made here. --> A decision tables' inputs and outputs must have an id and can have a name. The name (or label) is not mandatory. Even though the internal decision engine was already able to deal with this, the workflow engine wasn't. It would try to write the EvaluationEvent record with an EvaluatedInputRecord (or EvaluatedOutputRecord) and then fail writing it because of a NullPointerException. This makes sure these records can be written when the name of the input or output is undefined. ## Related issues <!-- Which issues are closed by this PR or are related --> closes #8909 Co-authored-by: Nico Korthout <nico.korthout@camunda.com>
ghost
pushed a commit
that referenced
this issue
Mar 21, 2022
8919: Support decision table inputs and outputs without names/labels r=korthout a=korthout ## Description <!-- Please explain the changes you made here. --> A decision tables' inputs and outputs must have an id and can have a name. The name (or label) is not mandatory. Even though the internal decision engine was already able to deal with this, the workflow engine wasn't. It would try to write the EvaluationEvent record with an EvaluatedInputRecord (or EvaluatedOutputRecord) and then fail writing it because of a NullPointerException. This makes sure these records can be written when the name of the input or output is undefined. ## Related issues <!-- Which issues are closed by this PR or are related --> closes #8909 Co-authored-by: Nico Korthout <nico.korthout@camunda.com>
ghost
closed this as 
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Error: https://console.cloud.google.com/errors/detail/CIHdh_bs1r-nDQ;service=zeebe;time=P7D?project=camunda-cloud-240911
Expected behavior
Log/Stacktrace
Full Stacktrace
Environment:
The text was updated successfully, but these errors were encountered: