argoproj/argo-workflows · error
failed to update cluster workflow template: %s, %w
Error message
failed to update cluster workflow template: %s, %w
What it means
After fetching the current resourceVersion, updateClusterWorkflowTemplates calls serviceClient.UpdateClusterWorkflowTemplate for each template. If that server-side update fails, the loop returns this error wrapping the underlying cause with the template name. Typical underlying causes are OptimizedConflict (resourceVersion changed concurrently), validation rejection, or RBAC denial.
Source
Thrown at cmd/argo/commands/clustertemplate/update.go:70
if err != nil {
return err
}
clusterWorkflowTemplates := generateClusterWorkflowTemplates(ctx, filePaths, cliOpts.strict)
for _, wftmpl := range clusterWorkflowTemplates {
current, err := serviceClient.GetClusterWorkflowTemplate(ctx, &clusterworkflowtemplate.ClusterWorkflowTemplateGetRequest{
Name: wftmpl.Name,
})
if err != nil {
return fmt.Errorf("failed to get existing cluster workflow template %q to update: %w", wftmpl.Name, err)
}
wftmpl.ResourceVersion = current.ResourceVersion
updated, err := serviceClient.UpdateClusterWorkflowTemplate(ctx, &clusterworkflowtemplate.ClusterWorkflowTemplateUpdateRequest{
Template: &wftmpl,
})
if err != nil {
return fmt.Errorf("failed to update cluster workflow template: %s, %w", wftmpl.Name, err)
}
printClusterWorkflowTemplate(updated, cliOpts.output.String())
}
return nil
}
View on GitHub (pinned to 35bff19146)
Solutions
- Re-run `argo cluster-template update` — a fresh Get picks up the new resourceVersion and the retry usually succeeds
- Serialize updates: ensure only one pipeline/process updates a given template at a time (locks, separate files per team)
- Inspect the wrapped error (%w) for a validation message and fix the offending fields in the manifest
- Fix RBAC so the caller's identity can update clusterworkflowtemplates.argoproj.io
Example fix
// before argo cluster-template update ./templates # fails with conflict under concurrent writers // after for i in 1 2 3; do argo cluster-template update ./templates && break || sleep 5; done
Defensive patterns
Strategy: retry
Validate before calling
// pre-check no concurrent writers: capture resourceVersion and re-check argo cluster-template get "$TMPL_NAME" -o json | jq -r '.metadata.resourceVersion'
Try / catch
for i in 1 2 3 4 5; do argo cluster-template update "$f" && break case $? in 0) break;; *) sleep $((i*5));; esac done
Prevention
- Serialize updates per template across pipelines (locks/queues)
- Always re-Get before Update so resourceVersion is fresh
- Keep one canonical source (GitOps) for each ClusterWorkflowTemplate
- Read the wrapped error to distinguish conflict (retry) from validation (fix manifest)
When it happens
Trigger: `argo cluster-template update` when: another writer modified the ClusterWorkflowTemplate between the Get and Update (stale resourceVersion → conflict); the updated spec fails server-side validation; the identity lacks update permission on clusterworkflowtemplates; the argo server cannot reach the k8s API.
Common situations: Two CI pipelines updating the same ClusterWorkflowTemplate concurrently; editing a template whose stored version was bumped by a controller/other user mid-run; admission webhooks or CRD validation rejecting new field values.
Related errors
- failed to get existing cluster workflow template %q to updat
- unknown output mode: %s
- invalid shell %q: supported shells are bash, zsh, and fish
- error converting %s: %w
- failed to parse TypeMeta: %w
AI-assisted analysis of argoproj/argo-workflows@35bff19146 (2026-09-03).
Data as JSON: /api/errors/ec33938647a2ee37.
Report an issue: GitHub.