apache / incubator-kie-issues

Apache License 2.0
11 stars 1 forks source link

DMN New Editor backward incompatibility for data type expression constraints #1341

Open jomarko opened 1 week ago

jomarko commented 1 week ago

This seems to be a very interesting issue of using New vs Classic DMN editor.

We have this DMN model, from its content, created probably using the Classic DMN Editor.

reproducer.dmn.txt

Please notice, it contains invalid constraint definition not(null) and (string length()>0). But it is good four reporting this issue.

New DMN Editor

Once you upload the model into sandbox, fill some string for the user, you will see error. This is expected. Screenshot 2024-06-21 093042

Then fix the constraint to be string length(?)>0), and again check the run results. There will be still an error. This is not expected. Screenshot 2024-06-21 093107

New DMN Editor

DO the same steps as with New DMN editor using Classic editor. In the first phase, the error will be the same, that is expected. Screenshot 2024-06-21 093150

In the second phase, the classic editor will start to work and user see the execution results. This is correct behavior that should be also for the NEW DMN Editor. Screenshot 2024-06-21 093223

gitgabrio commented 1 week ago

Thanks @jomarko @baldimir @yesamer : there is a strange behavior here, beside the one mentioned by Jozef. The original dmn is invalid -> string length()>0 because lenght() requires a parameter, but in my local test it succeed validation, and even the behavior from editors suggest that, since the error is thrown during execution, and not during import (IINW) 🤔

gitgabrio commented 1 week ago

@baldimir @yesamer On further investigation, here's the issues I found:

  1. the constraint is invalid in first place, but constraints are not checked during validation
  2. during execution, the constraint fails because of the wrong syntax (i.e. there is a method not found error) but this is swalloped up and hidden
  3. due to above, the end result of the unarytest is "null", so the message misleading says that "a" is invalid, while it is actually valid (it is the constraint itself that is wrongly written)