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

  1. Re-run `argo cluster-template update` — a fresh Get picks up the new resourceVersion and the retry usually succeeds
  2. Serialize updates: ensure only one pipeline/process updates a given template at a time (locks, separate files per team)
  3. Inspect the wrapped error (%w) for a validation message and fix the offending fields in the manifest
  4. 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

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


AI-assisted analysis of argoproj/argo-workflows@35bff19146 (2026-09-03). Data as JSON: /api/errors/ec33938647a2ee37. Report an issue: GitHub.