Pre-requisites
What happened? What did you expect to happen?
After upgrading from v3.7.10 to v4.0.4, using {{inputs.parameters.xxx}} in the name field of a step is no longer accepted. This worked fine in v3.7.10.
During validation (before execution), Argo replaces the parameter with an internal placeholder:
regen-{{inputs.parameters.date}} → regen-__argo__internal__placeholder-3305
In v3.7.10, parameters were resolved before name validation, so names like regen-05-02 were valid. In v4.0, validation now runs before parameter resolution, causing the placeholder (which contains underscores) to fail Kubernetes naming rules.
Error message:
name 'regen-__argo__internal__placeholder-3305' is invalid: name must consist of
alpha-numeric characters or '-', and must start with an alpha-numeric character
(e.g. My-name1-2, 123-NAME)
This also breaks when expressions that reference dynamic step names, since the step name is no longer resolved dynamically:
when: "{{steps.regen-{{inputs.parameters.date}}.status}} != Succeeded"
This is related to #14329 and PR #15744 which fixed the same placeholder leak mechanism for inline template script sources. The root cause appears to be the same (ProcessArgs substituting validation placeholders too early), but applied to a different location: the step name field instead of the script source field.
Version(s)
v4.0.4
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: test-dynamic-step-name-
spec:
entrypoint: main
arguments:
parameters:
- name: date
value: "2024-01-15"
templates:
- name: main
steps:
- - name: process-day
template: day-loop
arguments:
parameters:
- name: date
value: "{{workflow.parameters.date}}"
- name: day-loop
inputs:
parameters:
- name: date
steps:
- - name: run-{{inputs.parameters.date}}
template: worker
arguments:
parameters:
- name: date
value: "{{inputs.parameters.date}}"
continueOn:
failed: true
- - name: check-{{inputs.parameters.date}}
template: worker
arguments:
parameters:
- name: date
value: "{{inputs.parameters.date}}"
when: "{{steps.run-{{inputs.parameters.date}}.status}} != Succeeded"
- name: worker
inputs:
parameters:
- name: date
container:
image: busybox
command: [echo]
args: ["Processing {{inputs.parameters.date}}"]
Logs from the workflow controller
$ argo lint test-dynamic-step-name.yaml
test-dynamic-step-name.yaml:
✖ in "test-dynamic-step-name-" (Workflow): templates.main.steps[0].process-day
templates.day-loop.steps[0].name 'run-__argo__internal__placeholder-12' is invalid:
name must consist of alpha-numeric characters or '-', and must start with an
alpha-numeric character (e.g. My-name1-2, 123-NAME)
Logs from in your workflow's wait container
Pre-requisites
:latestimage tag (i.e.quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on:latest. If not, I have explained why, in detail, in my description below.What happened? What did you expect to happen?
After upgrading from v3.7.10 to v4.0.4, using
{{inputs.parameters.xxx}}in thenamefield of a step is no longer accepted. This worked fine in v3.7.10.During validation (before execution), Argo replaces the parameter with an internal placeholder:
In v3.7.10, parameters were resolved before name validation, so names like
regen-05-02were valid. In v4.0, validation now runs before parameter resolution, causing the placeholder (which contains underscores) to fail Kubernetes naming rules.Error message:
This also breaks
whenexpressions that reference dynamic step names, since the step name is no longer resolved dynamically:This is related to #14329 and PR #15744 which fixed the same placeholder leak mechanism for inline template script sources. The root cause appears to be the same (
ProcessArgssubstituting validation placeholders too early), but applied to a different location: the stepnamefield instead of the scriptsourcefield.Version(s)
v4.0.4
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container