fix(orchestrator): workflow start state might also be in the start.stateName variable when compiled and cloudevent input data should be one level deep

[lholmquist]

Hey, I just made a Pull Request!

While i was testing the Emitting Cloud Events to Trigger workflows on an Openshift cluster, using "compiled" workflows instead of running them in dev mode on my laptop, I ran into this error: "Error executing workflow with id lock-flow, No States that match the start state"

I discovered that the "start" parameter might also have another parameter in it that needs to be taken into account.

For example, The previous code assumed that when parsing the source for the "start" param it would look like this:

id: lock-flow
name: Kafka and Cloud events demo
...
start: listenToLock

code example from here: https://github.com/masayag/poc-kafka-logic-operator/blob/main/callback-flow/src/main/resources/lock.sw.yaml

When i ran the "compiled" version of this workflow, using the manifests that are generated when building the workflow, the source looks more like this:

start:
      stateName: listenToLock

code example from here: https://github.com/masayag/poc-kafka-logic-operator/blob/main/manifests/02-sonataflow_lock-flow.yaml

This code change checks for that "stateName" param and uses it if available, it not then falls back to just the "start" param

The other thing that I came across was when a workflow has input data from a form sent to it. The inputData object will look like this:

{
  workflowData: {
    input1: Data,
    input2: moreData
  }
}

and the data section of the cloud event would look something like this: data: { workflowData: {} } which will error the workflow when the kafka message sends the data back. The input data that is added to the data section of the cloudevent should just be the workflowData level and not the nested object. I added that fix here too

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or Updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-orchestrator-backend	workspaces/orchestrator/plugins/orchestrator-backend	patch	v8.9.2

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@5d17950). Learn more about missing BASE report.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2896   +/-   ##
=======================================
  Coverage        ?   33.21%           
=======================================
  Files           ?      162           
  Lines           ?     5904           
  Branches        ?     1554           
=======================================
  Hits            ?     1961           
  Misses          ?     3636           
  Partials        ?      307           

Flag	Coverage Δ
orchestrator	33.21% <100.00%> (?)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5d17950...5ce42c2. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[lholmquist]

@AndrienkoAleksandr thanks for the suggestions, updated