I agree with most of what you've said and found this issue while trying to find documentation with details on the differences. Is it safe to say that "Current Sync Status" is showing the current known state of the repository being pulled ("Pull State")? And "Last Sync Result" is the sync/kubectl apply state of the deployment/cluster ("Manifest Sync State")?

Is this just waiting on a PR? I think this would greatly help non-daily users quickly understand the UI.

my question is,

if "current sync status" and "last sync status" are targetting on different commit id, what I need do?

I have set auto-sync already, how to trigger argocd to do the deployment automatically?

Just waiting?

Regarding the second request, a commit SHA in a repo does not necessarily involve changing the desired state for a particular application and in my view the "last sync result" field should always point to the last commit that actually made the application OutOfSync and synced it. Auto sync does this, but not the manual sync button (it updates the commit SHA regardless).

If you have 9 commits not changing the desired state of a particular application it makes sense in my view that "last sync result" (or your proposal "live state") "lags behind" 9 commits from the "current sync status".

@ozbillwang It depends if the commit sha in "current sync status" actually changed something for the particular application.

"current sync status" is the latest commit that ArgoCD has looked at in the repo.
"last sync status" is the latest commit ArgoCD has applied to k8s for this particular application based on seeing a diff / app being out of sync.

So if your commit in "current sync status" did not change anything for a particular application (like updating README in the repo), the "last sync result" will not update to this new commit sha that did not change anything for your application object. This is the behaviour when auto sync is used. Try to click the "Sync" button and you will most likely see both commit SHA's becoming the same since that happens when doing it manually.

Found some more doc on auto update semantics here:

Automated Sync Semantics

"current sync status" is the latest commit that ArgoCD has looked at in the repo.
"last sync status" is the latest commit ArgoCD has applied to k8s for this particular application based on seeing a diff / app being out of sync.

I think this is the opposite of what I thought these meant. It really seems like "sync" is referring to two different things being synced here, right? One is syncing to argocd (what does ArgoCD know about the manifest "source") and one is argocd syncing to the cluster.

@djhoese Yea exactly as you say about two different things:

Repo <--- (current sync / default 3 min reconcile)---| ArgoCD |--- (last sync status) ---> k8s

If you want the same behaviour as auto sync in UI you can use "Refresh" which diffs manifest and only sync changes if it see any changes.

Imo a bit confusing that manual sync button in UI and auto sync behaves differently. Refresh button and auto sync seems to be the ones behaving the same.

Thanks for the decussion and explanation, @bestrand @djhoese

In between of current sync status and last sync status, if I use the applicaiton docker image with latest tag, the whole kubernetes deployment codes (yaml files) have no any changes, but the image itself with change, but same tag.

Can ArgoCD detect the difference and synd (I mean pull image always option with rolling update) ?

So my final question is,

Can I ask to merge current sync status and last sync status into one. Sync is sync, no concept of last or current sync status. It just makes confusion with no help.

The last sync status, always mislead me to think about this feature is used for rolling back to preview successful deployment

Can I ask to merge current sync status and last sync status into one. Sync is sync, no concept of last or current sync status. It just makes confusion with no help.

@ozbillwang As described above, sync is not just sync. There are two things being synced here. Repo -> ArgoCD -> Cluster. I personally would like to have at least some way of knowing both statuses. The main problem is that the UI only makes a distinction between these two (I think? that's how confusing it is to me) by using "current" versus "last".

Just adding to the voice of non expert users who are mighty confused.
ArgoCD in some organizations is the only touch point between devs and devops. In places like this, the distinction is far from intuitive to the devs

@djhoese

Regarding this comment

There are two things being synced here. Repo -> ArgoCD -> Cluster.

I am not really care of stage of Repo -> ArgoCD. For this part, I can check the commit id and confirm easily

I agree that this UI is super unintuitive.
Could I suggest a change like this, which matches the language used in their tooltips:
CURRENT SYNC STATUS -> REPO SYNC STATUS
LAST SYNC STATUS -> APP SYNC STATUS

The introduction of the temporal term variation between the two just makes it super misleading--the natural interpretations of two "current" and "last" UI elements next to one another is that one shows the same state of version N and the other of version N-1.
No one is going to get confused by dropping the LAST from the app sync label, if there's only one UI displaying app status then people will naturally know that's the representation of the state. And the full details will still be in the tooltip.

I'd be happy to submit a PR if it would be accepted, even though I'm not a front-end person :D

LAST SYNC => REPO SYNC
SYNC STATUS => APP STATUS

This has the benefit of not using sync twice (and not using status twice for that matter).

Fwiw, here's what ArgoCD looks like today (it's still confusing, a coworker complained to me today):

Whatever gets the change across the line I'd be happy with lol

In my case both "LAST SYNC RESULT" and "CURRENT SYNC RESULT" shows same commit id but the status is different ? what does this mean and what are the implications of it on application?

@nitinchavan01: you probably have things that need to be pruned or manually resolved (e.g. a statefulset where you changed an immutable field). On the left, there's an out of sync filter, use it and then look at the objects that are shown....

@jsoref we did tried the suggestion but all in vein. see below screens for reference.

You're going to have to look at the diff for the HPA, it's possible that you are using non-canonical values...

There's some descriptions about sync and refresh
https://argo-cd.readthedocs.io/en/stable/core_concepts/

In my case both "LAST SYNC RESULT" and "CURRENT SYNC RESULT" shows same commit id but the status is different ? what does this mean and what are the implications of it on application?

We are also stuck with this right now.

Sync status shows "OutOfSync" while Sync Result shows "Sync OK". No Warnings. Last sync results keeps refreshing every second.
What is going on here?

You should visit Slack.

There are lots of possible reasons for outofsync...
Usually you can filter (on the left) for out of sync to see what's going on. It could be...

• things that need to be pruned (you can resolve by pruning or manually deleting)
• attempts to change immutable properties (which typically is resolved by manually deleting)
• multiple apps manipulating the same objects
• ...

@jsoref Thanks, Slack helped. Our volume mounts did not contain a readOnly: true option, but somehow that is added automatically by something in the chain. Argo then seems to detect this option (which we never set) as Diff and continuously tries to sync something that never existed. Adding the option in our config resolved the infinite sync loop. Sorry for the off-topic post.

Just found this issue because what was displayed in the UI baffled me and I expected both "sync status" values to be the same. After reading through the thread, I now understand the difference. I like the proposals made above (e.g. #7629 (comment) or #7629 (comment)). What is missing to implement this change? Would surely help lots of people new to ArgoCD (like me).

It's actually a painful change to think through -- I've occasionally thought about making a PR for this (I'm trying now...).

Part of my frustration, is that I believe that the items I've outlined in rounded rectangles and drawn connected lines are vaguely related whereas other things that happen to have similar names are not:

The terminology is also used at a number of layers (likely including some dependent components and definitely including sibling argoproj projects).
Here's my poor understanding of things:

1. The sync status button at the top shows a screen has info from the last sync field, has no health info, and no sense of out of sync (so no relation to any of the items on the left side)
   
2. The last sync box on the right has information that appears in the view linked when clicked from the sync status button
   
3. the sync status box seems to have similar information relative to the sync status filter box
   
4. the sync status filter box applies the same kind of state -- but to individual objects -- as the sync status box
   
5. the app health status box seems to have similar information relative to the health status filter box
   
6. the health status filter box applies the same kind of state -- but to individual objects -- as the app health status box
   

@jsoref I really like the idea of having the sync button look different when there is a sync to be done. That's cool.

Oh, I wasn't precisely planning on changing it dynamically. For now I just don't want it to be confused for the two rather unrelated other labels that currently also have the same text.

It probably would make sense for the button to visibly change a bit when we know something isn't synced. But let's first try to decouple these text elements.

Reading from left to right in terms of importance to see the status of the app, it seems like the sync statuses should be the other way round. Maybe something like:

• App health - is the running app healthy
• App sync - is the sync relevant to this app healthy (what is "last synced" today)
• Repo sync - can argocd sync with the repo as a whole.