The task `run: script` is meant to run embedded as part of the workflow definition

[fjtirado]

I tried this:

Java SDK reference implementation was broken because of #1129

This happened:

Unfortunately this PR breaks SDK Java reference implementation for scripts.
The PR was assuming that a script implementation will consist on an external call to the os script command , which as the Java implemenation proof, is not necesarily true.
We should partially revert it.
We should remove stdin argument for script call, and revert back script arguments from list to map (since both JS and Python supports named arguments). Then we restore the deleted script example (that was a clear indication of breakign backward compatibilitty that should have prevented the merge) and remove the script example that was added.
We can keep new stdin argument for shell and container (it is optional and a nice addition).

I expected this:

No response

Is there a workaround?

No response

Anything else?

No response

Area(s)

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.name: Bug Report 🐞

[fjtirado]

For references, see how Map of arguments are handled in SDK reference implementation (and why this should have not been changed)

For JS and Python, they are used as named arguments, as supported by the languages

JS implementation is embedded

https://github.com/open-workflow-specification/sdk-java/blob/main/impl/javascript/src/main/java/io/serverlessworkflow/impl/executors/script/js/JavaScriptScriptTaskRunner.java#L77

And it can run this example

https://github.com/open-workflow-specification/sdk-java/blob/main/impl/test/src/test/resources/workflows-samples/run-script/console-log-args.yaml

Python one is base command line, but still it can handle named args gracefullly

https://github.com/open-workflow-specification/sdk-java/blob/main/impl/python/src/main/java/io/serverlessworkflow/impl/executors/script/python/PythonScriptTaskRunner.java#L55-L64

For shell, we are compounding name=value as shell argument, if value is present
https://github.com/open-workflow-specification/sdk-java/blob/main/impl/core/src/main/java/io/serverlessworkflow/impl/executors/RunShellExecutor.java#L54-L60

So you can have only key ones
https://github.com/open-workflow-specification/sdk-java/blob/main/impl/test/src/test/resources/workflows-samples/run-shell/echo-with-args-only-key.yaml
or key-value ones
https://github.com/open-workflow-specification/sdk-java/blob/main/impl/test/src/test/resources/workflows-samples/run-shell/echo-with-args-key-value-jq.yaml (so the key part is fixed and the value result of an argument evalution, heavily improving user experience)

[fjtirado]

This is the proposed diff
Note that stdin is removed for Script, because as mentioned in slack it is of dubious utility for scripts, but it can be kept.
What needs to be restored (because it breaks current implementation) is the arguments to be a map rather than a list. Note that a map can be converted to a list so other implementations will still work with reasonable trivial changes, while the opposite is not true (converting a list to map should be based on arg position, which is really ugly),
Besides that, having a map allows user to define narrower jq expressions, which improves user experience, as shown in previous comment.

diff --git a/schema/workflow.yaml b/schema/workflow.yaml
index 88c92bd..b997524 100644
--- a/schema/workflow.yaml
+++ b/schema/workflow.yaml
@@ -877,16 +877,11 @@
                       type: string
                       title: ScriptLanguage
                       description: The language of the script to run.
-                    stdin:
-                      type: string
-                      title: ScriptStdin
-                      description: A runtime expression, if any, to the script as standard input (stdin).
                     arguments:
-                      type: array
+                      type: object
                       title: ScriptArguments
-                      description: A list of the arguments, if any, to the script as argv
-                      items:
-                        type: string
+                      description: A key/value mapping of the arguments, if any, to use when running the configured script.
+                      additionalProperties: true
                     environment:
                       type: object
                       title: ScriptEnvironment
@@ -929,11 +924,10 @@
                       title: ShellStdin
                       description: A runtime expression, if any, to the shell command as standard input (stdin).
                     arguments:
-                      type: array
+                      type: object
                       title: ShellArguments
-                      description: A list of the arguments, if any, to the shell command as argv
-                      items:
-                        type: string
+                      description: A list of the arguments of the shell command to run.
+                      additionalProperties: true
                     environment:
                       type: object
                       title: ShellEnvironment

[ricardozanini]

Disclaimer: I used AI to organize my ideas before submiting a PR.

---

Assessment of Issue #1180

What PR #1129 Changed

PR #1129 by @hirenr made three changes to run:script and run:shell:

1. Changed arguments from object (map) to array (string list) — for script, shell, and container
2. Added stdin — a new string property on all three (script, shell, container)
3. Deleted the old run-script-with-arguments.yaml example — which used map-based arguments — and replaced it with a new stdin+argv example

PR #1129 Author's Rationale

The author's motivation was to align the spec with a CLI/OS execution model:

• Arguments as string[] map directly to argv (positional CLI arguments)
• stdin provides a clean separation between data input (piped via stdin) and arguments
• Avoids "injection of code into scripts" — data goes through stdin, not embedded in script code
• Makes scripts "portable" — they work the same way inside and outside the workflow engine

Why This Breaks the Java SDK (and the Spec Philosophy)

@fjtirado makes a strong case that the change was misguided for scripts specifically:

1. Scripts are not CLIs. The PR assumed scripts are invoked as external OS commands (like node script.js arg1 arg2). But the Java SDK embeds script execution — JavaScript runs via GraalJS, Python via Jython/subprocess. Named arguments map naturally to language features:

   • JS: arguments map entries become named variables accessible in the script (e.g., console.log(greetings) — see
     console-log-args.yaml)
   • Python: map entries become named arguments
   • Shell: map entries become --key=value or positional flags (see
     echo-with-args-key-value-jq.yaml)

2. A map is strictly more expressive than a list. You can always convert {a: 1, b: 2} to ["a", "1", "b", "2"], but you can't go the other way without convention-based parsing. The old map format let users write focused jq expressions like '--user': '${.user}' with clear semantics.

3. The deleted example was a red flag. The old run-script-with-arguments.yaml used arguments: {message: "${ .message }"} and console.log(message) — direct named variable access. PR feat: baseline run:script, run:container and run:shell to support stdin and argv #1129 deleted it because it no longer fit the new array model, which should have signaled backward incompatibility.

4. stdin for scripts is dubious. For embedded script engines (GraalJS, Jython), there's no real stdin pipe. It only makes sense when scripts are executed as OS subprocesses.

Proposed Fix

Property	Script	Shell	Container
arguments	Revert to object (map)	Revert to object (map)	Keep as array (makes sense for CMD argv)
stdin	Remove (dubious for embedded engines)	Keep (useful for piping data)	Keep (useful for piping data)

For container, keeping arguments as an array makes sense — containers genuinely receive argv via their entrypoint/CMD. But for scripts and shell commands, the map format is more expressive and better matches how SDK implementations actually work.

The example run-script-with-stdin-and-arguments.yaml should be replaced with the restored original run-script-with-arguments.yaml, and run-shell-stdin-and-arguments.yaml should be updated to use the map format for arguments (while keeping stdin).