serverless foreach condition not honored

[chris-aeviator]

Describe the bug

When using the type: foreach state in the serverless workflow according to the v0.8 spec, kogito executes each action, even though a condition is present.

Expected behavior

Kogito only fires events/functions when a condition is met

Actual behavior

Kogito fires all events

How to Reproduce?

{
 "id": "actionPlanOrder",
 "name": "Action Plan Order",
 "version": "1.0.0",
 "specVersion": "0.8",
 "autoRetries": true,
 "start": "OrderActionplan",
 "constants": {
  "ACCOUNT": "Account",
  "AI": "AI"
 },
 "states": [
  
  {

    "name": "OrderActionplan",
    "type": "event",
    "onEvents": [{
      "eventRefs": [
        "OrderActionplan"
      ]
    }],
    "transition":"ProcessOrders"
  },
  {
   "name": "ProcessOrders",
   "type": "foreach",
   "inputCollection": "${ .customer.orders }",
   "iterationParam": "tx",
   "actions": [
    {
     "name": "Process Account Creation Order",
     "eventRef": {
        "triggerEventRef": "OrderAccountCreation",
        "data": "${ .tx}"
      },
     "condition": "${ .tx.name == \"Account\" }"
    
    },
    {
     "name": "Process AI Creation Order",
     "eventRef": {
        "triggerEventRef": "OrderAICreation",
        "data": "${ .tx}"
      },
     "condition": "${ .tx.name== \"AI\" }"
    }
   ],
   "end": true
  }
 ],
 "functions": [
  {
   "name": "Actionplan Service - Account Order",
    "type":"custom",
    "operation": "service:java:org.tofu.ai.actionplans.EventsService::orderAccount" 
  },
  {
   "name": "Actionplan Service - AI Order",
    "type":"custom",
    "operation": "service:java:org.tofu.ai.actionplans.EventsService::checkReady" 
  }
 ],
  "events": [
    {
      "name": "OrderActionplan",
      "source": "",
      "type": "orderActionplan",
      "kind": "consumed"
    },
    {
      "name": "OrderAccountCreation",
      "source": "",
      "type": "orderAccountCreation",
      "kind": "produced"
    },
    {
      "name": "OrderAICreation",
      "source": "",
      "type": "orderAICreation",
      "kind": "produced"
    }
  ] 
}

send a message to orderActionplan with

"data": {"customer": {"orders": [{"name": "Account"}]}}}

consume orderAccountCreation , orderAICreation, orderActionplan

Only orderActionPlan & orderAccount should receive messages, but also orderAICreation will receive a messsage with data=:{name: "Account"}

Output of uname -a or ver

Linux korny-x1 5.18.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 30 May 2022 17:53:11 +0000 x86_64 GNU/Linux

Output of java -version

openjdk version "18.0.1.1" 2022-04-22 OpenJDK Runtime Environment (build 18.0.1.1+2) OpenJDK 64-Bit Server VM (build 18.0.1.1+2, mixed mode)

GraalVM version (if different from Java)

No response

Kogito version or git rev (or at least Quarkus version if you are using Kogito via Quarkus platform BOM)

quarkus --version 2.16.4.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[hbelmiro]

@chris-aeviator I've created the following Jira to track it: https://issues.redhat.com/browse/KOGITO-8836

cc @fjtirado @ricardozanini

[fjtirado]

Action condition is not implemented for any state: foreach, operation or parallel. So, this is expected behaviour with the current implementaiton
I agree is a nice to have (altough similar behaviour can be achieved by using several swith states)

[ricardozanini]

@fjtirado can we update here? https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/getting-started/cncf-serverless-workflow-specification-support.html#states

[fjtirado]

@ricardozanini Problem is that we do not have an action section there, this is not particular to an state, but an action property we have not implemented because it is just a shortcut for a swith state (a simple one), so this not being implemented is not really reflected there.
Anyway, I think we can implement it (although there are some technical implication we will need to discuss)

[chris-aeviator]

I kind of achieved what I wanted by running foreach, passing stateData and starting a subflow to emit my events. I believe the spec is very much open to interpretation here. Do you have any experience/ ideas how other SW frameworks handle this?

[ricardozanini]

@ricardozanini Problem is that we do not have an action section there, this is not particular to an state, but an action property we have not implemented because it is just a shortcut for a swith state (a simple one), so this not being implemented is not really reflected there.

I understand, but we need to update the doc and say that we are not supporting it at the moment.

[ricardozanini]

I kind of achieved what I wanted by running foreach, passing stateData and starting a subflow to emit my events. I believe the spec is very much open to interpretation here. Do you have any experience/ ideas how other SW frameworks handle this?

To the best of my knowledge, Kogito is the one with the most features implemented. Maybe it's worth asking the CNCF community how the maintainers from other implementations are handling this.

[chris-aeviator]

are there tests in place to see which features are not up to spec? Also the 🌕 /🌗 notation might be not too accurate. A clear list of supported/ unsupported features is better in that regard.

[ricardozanini]

@chris-aeviator it's tricky to add a list of supported/unsupported since a few things are open for interpretation. We are doing our best to handle everything. We add to the doc what we understand it's supported at the moment and what we know it's not working. When we come up with situations like this one, we update the doc. But I agree that we could add a list to some extent in a few items.

[fjtirado]

@chris-aeviator https://issues.redhat.com/browse/KOGITO-8836 will be added on Kogito 1.36. The intepretation is clear, if the condition is not match, the action should be skipped.