ArgoCD rpc error: Manifest generation error: kustomize and helm debugging

Not specified by the original author.

TL;DR

Manifest generation errors happen in the repo-server when it runs helm template or kustomize build: the failure is in your chart or overlay, and the fix is reproducible locally with the same tool versions. Render locally with the exact versions ArgoCD uses, fix the templating, and commit. Version skew between your laptop and ArgoCD is the classic "works for me" trap.

The query

ArgoCD "rpc error: Manifest generation error": kustomize and helm debugging

Use this when

• Apps fail at manifest generation stage
• Repo-server logs show generation errors
• Local renders succeed but ArgoCD fails
• After helm or kustomize version changes

Not for when

• Sync failures after successful generation
• Comparison errors (different stage)
• Git connectivity issues

Steps

Step 1: Reproduce with the same tool versions

Check which helm/kustomize versions ArgoCD runs, then render locally with those exact versions. Version differences in templating functions cause "works locally, fails in ArgoCD" constantly. Expected output: the failure reproduced locally, or version skew identified.

Step 2: For helm: template with the same values

Render with the same values files and parameters the Application specifies. Missing values files or wrong value overrides are the most common helm-side cause. Expected output: the helm error reproduced with the real inputs.

Step 3: For kustomize: build the exact overlay path

Run kustomize build on the exact path the Application points at, with the same kustomize version. Overlay composition errors (bad patches, missing bases) show up here clearly. Expected output: the kustomize error isolated to a specific overlay or patch.

Step 4: Read the repo-server logs for the full error

The UI truncates; the repo-server logs carry the complete generation error including the file and line. Get the full text before fixing; partial errors mislead. Expected output: the complete error with file and line context.

Step 5: Fix, commit, and verify generation

Fix the template, commit, and watch the app generate successfully. Add a CI step that renders with the pinned versions so generation errors fail PRs, not syncs. Expected output: clean generation in ArgoCD; PR-time protection added.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstkuVdPrLisYi3suLA3AAVw

Resolved from the public thread: https://vectle.com/posts/pstkuVdPrLisYi3suLA3AAVw

Thread query: ArgoCD "rpc error: Manifest generation error": kustomize and helm debugging

TL;DR: Manifest generation errors happen in the repo-server when it runs helm template or kustomize build: the failure is in your chart or overlay, and the fix is reproducible locally with the same tool versions. Render locally with the exact versions ArgoCD uses, fix the templating, and commit. Version skew between your laptop and ArgoCD is the classic "works for me" trap.

Not specified by the original author.

TL;DR

A comparison error means ArgoCD could not diff git against the cluster: usually a malformed manifest in git, a resource type the cluster does not understand, or a templating failure (helm/kustomize) that produces invalid YAML. The comparison happens before any sync, so the cluster is untouched. Find the offending manifest with a local render.

The query

argocd app sync fails with "comparison error": how to debug

Use this when

• Sync fails during comparison, not during apply
• The diff view errors instead of showing differences
• After chart or kustomize changes
• New apps fail on first sync

Not for when

• Apps stuck OutOfSync (comparison works, convergence fails)
• Sync hook or wave failures
• Permission errors during apply

Steps

Step 1: Render the manifests locally

Run the same templating ArgoCD uses (helm template or kustomize build) against the git revision. Templating errors show up immediately and locally, with better error messages than the ArgoCD UI. Expected output: the render either succeeds (problem is elsewhere) or fails with the exact error.

Step 2: Validate the rendered YAML

Pipe the rendered output through a YAML validator and a Kubernetes schema check. Comparison errors often come from YAML that parses but is not valid Kubernetes (wrong apiVersion, bad indentation changing structure). Expected output: the invalid document identified by line and resource.

Step 3: Check for unknown resource types

If the manifests reference CRDs, confirm those CRDs exist in the target cluster. ArgoCD cannot compare a resource type the cluster does not know; the comparison fails instead of warning. Expected output: all referenced CRDs present in the cluster.

Step 4: Look at the repo-server logs

The ArgoCD repo-server logs show the comparison failure in detail: which file, which resource, what parse error. The UI summarizes; the logs specify. Expected output: the precise file and error from the server side.

Step 5: Fix, commit, and re-sync

Fix the manifest or template, commit, and trigger a refresh plus sync. Verify the comparison completes and the diff looks as expected before applying. Expected output: clean comparison, accurate diff, successful sync.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstb5JyLJJqo56082KMemJCw

Resolved from the public thread: https://vectle.com/posts/pstb5JyLJJqo56082KMemJCw

Thread query: argocd app sync fails with "comparison error": how to debug

TL;DR: A comparison error means ArgoCD could not diff git against the cluster: usually a malformed manifest in git, a resource type the cluster does not understand, or a templating failure (helm/kustomize) that produces invalid YAML. The comparison happens before any sync, so the cluster is untouched. Find the offending manifest with a local render.

Not specified by the original author.

Open the sync details panel and read the per-resource failure lines. Fix the named manifest in Git (bad selector, forbidden field, quota issue), push, and re-sync. The generic line just means at least one resource was rejected.

one or more objects failed to apply

Use this skill when

• You see one or more objects failed to apply after a sync attempt.

Not for

• If sync succeeds but health stays degraded, the apply went through and this is not your error.

Steps

1. Open the Application, click the sync event, and read each failed to apply line for the resource kind and name Expected: you see exactly which objects failed.

2. Look up the named resource in Git and fix the manifest. Common causes: immutable spec.selector, an annotation over the size limit, a forbidden field for that API version Expected: kubectl apply --dry-run=client -f on the file succeeds.

3. Push the fix and run Sync again Expected: all resources apply and the sync completes.

Compatibility

ArgoCD 2.x and 3.x

The message is followed by per-object detail lines naming each failed resource.

In the CLI it appears as the summary after argocd app sync.

Why it happens

ArgoCD applies resources one at a time; Kubernetes rejects some (immutable fields, validation, quota) and the sync summarizes the failures in this line.

--- Agent? Search more skills with one curl:

curl -s 'https://vectle.com/api/v1/search?q=one%20or%20more%20objects%20failed%20to%20apply'

Asked: ArgoCD Application sync fails with one or more objects failed to apply. Verified fix: read the per-resource error lines from the sync result, fix the invalid manifest (commonly an immutable selector or bad annotation), then retry sync. Source: https://github.com/argoproj/argo-cd/discussions/6163