Failed to resolve output parameter when using templateRef

[fvicent]

Hi there. I'm facing a very strange behavior with one of my production workflows which I managed to isolate into the following example. I have this simple workflow (my-workflow.yaml) which defines a DAG with two tasks:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: my-workflow-working
  generateName: my-workflow-working-
spec:
  entrypoint: my-workflow-working-entrypoint
  templates:

    - name: load
      container:
        image: alpine:latest
        command: ["sh"]
        args:
          - "-c"
          - "echo -n hello world > /tmp/hello_world.txt"
      outputs:
        parameters:
        - name: message
          valueFrom:
            path: "/tmp/hello_world.txt"

    - name: print
      inputs:
        parameters:
          - name: message
      container:
        image: alpine:latest
        command: ["sh"]
        args:
          - "-c"
          - "echo -n {{inputs.parameters.message}}"
  
    - name: my-workflow-working-entrypoint
      dag:
        tasks:

        - name: task1
          template: load

        - name: task2
          dependencies: [task1]
          template: print
          arguments:
            parameters:
              - name: message
                value: "{{tasks.task1.outputs.parameters.message}}"

As you can see, there is a load template (used by task1) which loads a dummy message stored in a file and coverts it into an output parameter. The print template simply echoes the input parameter, which in task2 is the output parameter produced by task1. This runs perfectly fine and argo lint doesn't complain.

Now I want to decouple the print template into its own file, so I create my-template.yaml with the following content:

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: my-template
spec:
  templates:
    - name: print
      inputs:
        parameters:
          - name: message
      container:
        image: alpine:latest
        command: ["sh"]
        args:
          - "-c"
          - "echo -n {{inputs.parameters.message}}"

I go back to my-workflow.yaml to remove the print template definition and refactor the task2 so that it loads the template from my-template:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: my-workflow-broken
  generateName: my-workflow-broken-
spec:
  entrypoint: my-workflow-broken-entrypoint
  templates:

    - name: load
      container:
        image: alpine:latest
        command: ["sh"]
        args:
          - "-c"
          - "echo -n hello world > /tmp/hello_world.txt"
      outputs:
        parameters:
        - name: message
          valueFrom:
            path: "/tmp/hello_world.txt"
  
    - name: my-workflow-broken-entrypoint
      dag:
        tasks:

        - name: task1
          template: load

        - name: task2
          dependencies: [task1]
          templateRef:         # <----- This has changed.
            name: my-template  # <-----
            template: print
          arguments:
            parameters:
              - name: message
                value: "{{tasks.task1.outputs.parameters.message}}"

I apply my template with kubectl without any errors, and then run argo lint against my workflow. Now I get:

.\my-workflow-broken.yaml:
   ✖ in "my-workflow-broken" (Workflow): templates.my-workflow-broken-entrypoint.tasks.task2 templates.print: failed to resolve {{tasks.task1.outputs.parameters.message}}

And it won't let me submit the workflow neither. What could be causing this? Am I missing something?

I'm using a clean, local installation of Argo v.3.5.15.

argo: v3.5.15
  BuildDate: 2025-06-13T09:03:59Z
  GitCommit: b44c9b6a21cc60c00ef0cf3ca6a6a49e197a59b7
  GitTreeState: clean
  GitTag: v3.5.15
  GoVersion: go1.23.10
  Compiler: gc
  Platform: windows/amd64

Linting with v3.6 succeeds without any error, but since I'm using v3.5.15 in production, I would like to know if there is anything I can do to work around this without upgrading.

Thanks in advance.

[jswxstw]

I believe this issue is the same as #14165, which is caused by #14053 and was not reverted in v3.5.

[fvicent]

Seems to be the case. Thanks.