Align deployment rejection message for DMN resources

[saig0]

Describe the bug

If I deploy an invalid DMN resource then the deployment is rejected. The rejection message may look like the following example:

/bin/zbctl deploy ~/IdeaProjects/zeebe/engine/src/test/resources/processes/invalid_process.bpmn ~/IdeaProjects/zeebe/dmn/src/test/resources/decision-table-with-invalid-expression.dmn
Error: rpc error: code = InvalidArgument desc = Command 'CREATE' rejected with code 'INVALID_ARGUMENT': Expected to deploy new resources, but encountered the following errors:
'/home/philipp/IdeaProjects/zeebe/engine/src/test/resources/processes/invalid_process.bpmn': - Element: process
    - ERROR: Must have at least one start event

FEEL unary-tests: failed to parse expression '"blue': Expected (negation | positiveUnaryTests | anyInput):1:1, found "\"blue"

The rejection message for BPMN and DMN looks different. The rejection contains the failure message of the DMN but it is missing the related deployment resource. Without the resource, it could be hard to identify the failure.

To Reproduce

Deploy the following resources from the Zeebe repo.

/bin/zbctl deploy ~/IdeaProjects/zeebe/engine/src/test/resources/processes/invalid_process.bpmn ~/IdeaProjects/zeebe/dmn/src/test/resources/decision-table-with-invalid-expression.dmn

Expected behavior

The rejection message for DMN resources contains the name of the resource. Similar to the message for BPMN resources.

Error: rpc error: code = InvalidArgument desc = Command 'CREATE' rejected with code 'INVALID_ARGUMENT': Expected to deploy new resources, but encountered the following errors:
'/home/philipp/IdeaProjects/zeebe/engine/src/test/resources/processes/invalid_process.bpmn': - Element: process
    - ERROR: Must have at least one start event

'~/IdeaProjects/zeebe/dmn/src/test/resources/decision-table-with-invalid-expression.dmn': FEEL unary-tests: failed to parse expression '"blue': Expected (negation | positiveUnaryTests | anyInput):1:1, found "\"blue"

Log/Stacktrace

None.

Environment:

• OS:
• Zeebe Version: 1.4.0-alpha1
• Configuration:

[korthout]

Marking priority as later because DMN improvements are not a main priority for the process automation right now.

This issue may be interesting to pick up alongside the epics #8083 and #9864 (https://github.com/camunda/product-hub/issues/69)

Please comment if you think this should have a higher priority.

[jfriedenstab]

Hi @korthout, I'm currently working on process applications in Web Modeler (which will basically enable bundled deployments of multiple files) and stumbled across this issue. If the deployment bundle contains more than one invalid DMN diagram, you can't tell from the Zeebe response which error belongs to which file. So it would be nice if the DMN resource name could be included in the response (in the same way as it's already done for BPMN diagrams and forms).

[megglos]

ZPA-Triage:

• @jfriedenstab is this blocking the epic? if so is there any deadline you need this to be ready?
• for forms we append the resource name
• it's less of a bug but an inconsistency/limitation that makes it hard to link errors with the correct resource
• should be part of the related epic https://github.com/camunda/product-hub/issues/1983
  ==> given it's done for BPMN and forms already, seems a quick fix

[jfriedenstab]

Hi @megglos,

@jfriedenstab is this blocking the epic? if so is there any deadline you need this to be ready?

The Web Modeler epic is planned for 8.6.0-alpha1 (and on SaaS we'd like to release the feature even before if possible), so it would be nice if the problem could be fixed on the Zeebe side as soon as possible 🙃 (I just noticed that there's already a PR with a fix – great! 🎉).
I'd say it's not necessarily blocking for us; it would just make the user experience a bit worse if we couldn't clearly indicate which DMN diagram has an error.

[megglos]

@jfriedenstab fix is ready and will be part of 8.6.0-alpha1 #17475

[megglos]

@jfriedenstab do you also need this to be present in patches for previous minor releases or is 8.6 enough?

[jfriedenstab]

@megglos If it's easily possible, it would be nice to backport this at least to 8.4 and 8.5 (as we will support process application deployments to clusters >= 8.4).