ArgoCD shows error if it can't get description of a CRD irrelevant to application.

[utkarsh-opsmx]

Checklist:

• [V] I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• [V] I've included steps to reproduce the bug.
• [V] I've pasted the output of argocd version.

Describe the bug

While comparing app state ArgoCD tries to get all kubernetes resources (getApiResources() in sync() under cluster.go in gitops-engine) and iterate on it one by one. In our setup there is some CRD (from a third party vendor) that is present in the list of resources but when we get its description we get an error.
Although that CRD is not managed by/a dependency of the app whose state is being compared by ArgoCD, the CompareAppState() in state.go errors out. So just for a CRD that is corrupted sync for every app dependent or independent of the CRD errors out with the same error message.

Expected behavior

To compare app state ArgoCD should only list resources managed by app and iterate on it. Thus sync operation of the apps managing the CRD should error out and all.

Screenshots

The attached screenshot is of cluster sync but I get the same error while getting app state.

Version

2.13.0

Error Message

Failed to load live state: failed to get cluster info for " --------....(----): failed to load initial state of resource NodePool.karpenter.sh: conversion webhook for karpenter.sh/v1beta1, Kind=NodePool failed: Post "https://karpenter.kube-system.svc:8443/conversion/karpenter.sh?timeout=30s":

[ranakan19]

I'd like to work on this

[utkarsh-opsmx]

Hey @ranakan19 thanks!

I observed that sync() function here https://github.com/argoproj/gitops-engine/blob/v0.7.3/pkg/cache/cluster.go#L776
returns an error if there is some problem with loading the resource.
Maybe the return statment can be replaced by something which only logs the error and continues with the resource iteration. Just a suggestion.

[gopaljayanthi]

A k8s api resource endpoint for a custom resource definition can error out for a variety of reasons, example the controller related to the CRD may be down, this should not adversely effect the whole cluster and every application on that cluster.

[sbyrne-teck]

Hi @ranakan19 - any timeline estimates for the fix?

[ranakan19]

@sbyrne-teck Sorry missed your message, I'm working on this issue right now, PR coming out soon.

[ranakan19]

A few thoughts and follow-up questions:

1. Could you please share the output of argocd version to help us confirm the setup?
2. > when we get its description we get an error
   You mentioned encountering an error when fetching the description—could you clarify the exact error message and confirm if you're using kubectl describe?
3. I attempted to reproduce the issue by deploying a CRD with a broken conversion webhook. In my testing, I observed similar behavior only when an Application was created with the broken CRD or if I manually invalidated the cluster cache. Once the broken CRD was deleted, the cluster status recovered as expected. However if an application had no dependency to the broken CRD, just introducing the broken CRD did not affect cluster or application status.
4. I agree there's value in ensuring that one broken CRD doesn't affect the whole cluster. This aligns with concerns raised in other related issues, such as If any conversion webhook on any CRD isn't available, all apps on the cluster go to an "unknown" state. #20828. This seems to have broader implications at the gitops-engine level, so I plan to look into it further. However, resolving this will likely require careful discussion and alignment with the community to ensure we avoid unintended regressions.

[jcogilvie]

Would my PR fix this issue?