Title: UI: Deleting a rapidly-recreated resource from the tree returns "not found" (stale name after React 19 rewrite)
Labels: bug, component:ui, version:3.5
Checklist
Searched docs/FAQ and existing issues
Included reproduction steps
Included argocd version
Describe the bug
Since upgrading to 3.5 (React 19 UI rewrite), clicking DELETE on a resource in the application resource tree frequently fails with:
``Unable to delete resource: error deleting resource: pods "" not found"
This happens when the targeted resource has already been replaced in the cluster (e.g. a CrashLoopBackOff pod that the ReplicaSet/DaemonSet recreates, or any high-churn resource). The resource-tree panel appears to cache the resource name captured when the panel/dialog was opened and sends the delete for that name without re-validating against the current live tree. By the time the user confirms, the pod has a new name, so the API call 404s.
The live manifest panel simultaneously shows Resource not found in cluster: , confirming the UI is holding a stale reference.
In the React 16 UI (≤3.4) the tree refreshed more eagerly and the delete targeted the current pod, so this 404 was rarely/never seen.
To Reproduce
Deploy any workload with a pod that restarts/recreates frequently (e.g. a CrashLoopBackOff Deployment or a DaemonSet).
Open the application, open the pod in the resource tree.
Click DELETE (with or without Force).
If the pod was recreated between panel-open and confirm, the delete fails with pods "" not found.
Expected behavior
The UI should resolve the current live resource name (or re-fetch the tree node) at delete time, or gracefully treat a "not found" target as already deleted rather than surfacing an error.
Evidence (verified via CLI on the same cluster):
deleting the CURRENT live pod name succeeds
kubectl delete pod marketing-events-worker-646cbddd66-44w6b -n core-domain-dev
pod "...-44w6b" deleted
deleting a STALE (already-replaced) name reproduces the exact UI error
kubectl delete pod marketing-events-worker-646cbddd66-nb4lw -n core-domain-dev
Error from server (NotFound): pods "...-nb4lw" not found
This confirms the delete API is healthy; the failure is the UI sending an outdated resource name and version,
argocd: v3.5.2 (server), Helm chart argo-cd 10.4.1
Possible related
#29097 (React 19 UI regression: New App panel infinite render loop) — same React 19 UI rewrite.
Two notes before filing:
I referenced your app/pod names for concrete evidence — say the word and I'll anonymize them (e.g. my-worker-) before posting.
Filing posts publicly to argoproj/argo-cd under your GitHub account. Confirm you want it filed, and whether to anonymize, and I'll submit it.
`
Title: UI: Deleting a rapidly-recreated resource from the tree returns "not found" (stale name after React 19 rewrite)
Labels: bug, component:ui, version:3.5
Checklist
Searched docs/FAQ and existing issues
Included reproduction steps
Included argocd version
Describe the bug
Since upgrading to 3.5 (React 19 UI rewrite), clicking DELETE on a resource in the application resource tree frequently fails with:
``Unable to delete resource: error deleting resource: pods "" not found"
This happens when the targeted resource has already been replaced in the cluster (e.g. a CrashLoopBackOff pod that the ReplicaSet/DaemonSet recreates, or any high-churn resource). The resource-tree panel appears to cache the resource name captured when the panel/dialog was opened and sends the delete for that name without re-validating against the current live tree. By the time the user confirms, the pod has a new name, so the API call 404s.
The live manifest panel simultaneously shows Resource not found in cluster: , confirming the UI is holding a stale reference.
In the React 16 UI (≤3.4) the tree refreshed more eagerly and the delete targeted the current pod, so this 404 was rarely/never seen.
To Reproduce
Deploy any workload with a pod that restarts/recreates frequently (e.g. a CrashLoopBackOff Deployment or a DaemonSet).
Open the application, open the pod in the resource tree.
Click DELETE (with or without Force).
If the pod was recreated between panel-open and confirm, the delete fails with pods "" not found.
Expected behavior
The UI should resolve the current live resource name (or re-fetch the tree node) at delete time, or gracefully treat a "not found" target as already deleted rather than surfacing an error.
Evidence (verified via CLI on the same cluster):
deleting the CURRENT live pod name succeeds
kubectl delete pod marketing-events-worker-646cbddd66-44w6b -n core-domain-dev
pod "...-44w6b" deleted
deleting a STALE (already-replaced) name reproduces the exact UI error
kubectl delete pod marketing-events-worker-646cbddd66-nb4lw -n core-domain-dev
Error from server (NotFound): pods "...-nb4lw" not found
This confirms the delete API is healthy; the failure is the UI sending an outdated resource name and version,
argocd: v3.5.2 (server), Helm chart argo-cd 10.4.1
Possible related
#29097 (React 19 UI regression: New App panel infinite render loop) — same React 19 UI rewrite.
Two notes before filing:
I referenced your app/pod names for concrete evidence — say the word and I'll anonymize them (e.g. my-worker-) before posting.
Filing posts publicly to argoproj/argo-cd under your GitHub account. Confirm you want it filed, and whether to anonymize, and I'll submit it.
`