Describe the bug
The Orkes conductor docs (currently the only docs available for Conductor unless you dig in the archived Netflix repo) describe a simple usage pattern of a Dynamic Fork, when given a single task (or subworkflow) name to execute and an array of inputs to execute that task with.
This behaviour is not supported in the OSS version of Conductor. We are instead forced to make a preceding inline/worker task to generate dynamic task JSON definitions and task input mappings. This is overly complex and would result in a huge amount of boilerplate JSON for 100+ length array that all need the same task or sub-workflow to be executed.
Details
Using default conductor standalone docker image, taken from OSS Conductor ReadMe.
Conductor version: OSS 3.15
Persistence implementation: default (Redis)
Queue implementation: default (Postgres)
Lock: default (Redis?)
Workflow definition:
2. Add definitions above (no need to implement the worker to reproduce the bug, we won't make it that far)
3. Execute workflow with some array input, e.g. `{"numbers":[1,2,3,4]}`
4. See error: `Input to the dynamically forked tasks is not a map -> expecting a map of K,V but found null`
**Expected behaviour**
Input array should get split into 4 separate tasks (where 4 is array length) and processed concurrently in dynamic fork. As in [Orkes playground test run](https://play.orkes.io/execution/c278d24f-9e84-11ee-87d2-4a17fa5784e3).
**Screenshots**
Expected:
<img width="200" alt="image" src="https://github.com/conductor-oss/conductor/assets/93911737/46cc4a5b-6d9e-4aff-b19a-9e3119b2d27e">
Observed in OSS Conductor:
<img width="300" alt="image" src="https://github.com/conductor-oss/conductor/assets/93911737/129710a9-600d-49ed-99f1-6d19551e50e0">
Describe the bug The Orkes conductor docs (currently the only docs available for Conductor unless you dig in the archived Netflix repo) describe a simple usage pattern of a Dynamic Fork, when given a single task (or subworkflow) name to execute and an array of inputs to execute that task with.
This behaviour is not supported in the OSS version of Conductor. We are instead forced to make a preceding inline/worker task to generate dynamic task JSON definitions and task input mappings. This is overly complex and would result in a huge amount of boilerplate JSON for 100+ length array that all need the same task or sub-workflow to be executed.
Details Using default conductor standalone docker image, taken from OSS Conductor ReadMe. Conductor version: OSS 3.15 Persistence implementation: default (Redis) Queue implementation: default (Postgres) Lock: default (Redis?) Workflow definition:
Task definition:
Event handler definition: None
To Reproduce Steps to reproduce the behaviour:
docker run --init -p 8080:8080 -p 1234:5000 --mount source=redis,target=/redis \ --mount source=postgres,target=/pgdata conductoross/conductor-standalone:3.15.0