bug: app health "cool down" period not enforced when desire revision(s) are not specified

[krancour]

Discussed in #4593

^{Originally posted by AlanLonguet July 10, 2025}
I need a bit of help to determine if what we're observing is intended or not.

Our current promotion process revolves around committing the new version of an artifact in a repository that is directly watched by ArgoCD so it uses git-commit/git-push/argocd-update steps.

We've noticed that the argocd-update step only checks that the Application is correctly synced and does not wait for the full rollout of our pods which made us add verification steps that checks the rollout has happened.

We were wondering if that's intended behavior or an issue with our own setup.

Especially relevant comment:

While working for a bit on #4595/#4608, I stumbled upon a more probable explanation for your issue @AlanLonguet.

My best guess is that the workaround that was applied to correct for #2196 is insufficient in your case.

Apparently this "cool down" period is, mistakenly, not enforced when desired revision(s) are not specified by the argocd-update step. I would presume you have not specified any desired revision(s), as few users seem to do so.

I'm converting this discussion to an issue, and I've got a fix ready to go.

[AlanLonguet]

@krancour You're right we were in the case where we don't specify desiredRevision (We were doing this because specifying a commit can lead to issues since other commits could have been made between kargo commit and argocd-update step)