Skip to content

Conversation

@aali309
Copy link
Contributor

@aali309 aali309 commented Aug 19, 2025

Closes: #24190
Closes: #24296

Checklist:

  • Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
  • The title of the PR states what changed and the related issues number (used for the release note).
  • The title of the PR conforms to the Title of the PR
  • I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
  • I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
  • Does this PR require documentation updates?
  • I've updated documentation as required by this PR.
  • I have signed off all my commits as required by DCO
  • I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
  • My build is green (troubleshooting builds).
  • My new feature complies with the feature status guidelines.
  • I have added a brief description of why this PR is necessary and/or what this PR solves.
  • Optional. My organization is added to USERS.md.
  • Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

@bunnyshell
Copy link

bunnyshell bot commented Aug 19, 2025

❌ Preview Environment deleted from Bunnyshell

Available commands (reply to this comment):

  • 🚀 /bns:deploy to deploy the environment

@aali309 aali309 marked this pull request as ready for review August 20, 2025 01:20
@aali309 aali309 requested a review from a team as a code owner August 20, 2025 01:20
@aali309
Copy link
Contributor Author

aali309 commented Aug 20, 2025

@reggie-k, can you please review this for me! Thnx

Copy link
Member

@nitishfy nitishfy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for raising the PR. Can you please attach a demonstration video if possible?

@aali309
Copy link
Contributor Author

aali309 commented Aug 20, 2025

updatedFix.mov

@aali309 aali309 force-pushed the ProgressiveSyncUnknownInUI branch from d3f364a to aa63630 Compare August 20, 2025 18:28
Comment on lines 61 to 63
const hasRollingSyncEnabled = (application: models.Application): boolean => {
// Only show Progressive Sync for applications that have an ApplicationSet owner reference
// The actual strategy validation is done in the ProgressiveSyncStatus component
return application.metadata.ownerReferences?.some(ref => ref.kind === 'ApplicationSet') || false;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @aali309

It’s me from the reported issue: #24190 (comment) :)

Maybe I’m missing something, but wouldn’t it be more fitting to rename this function to hasApplicationSetParent or isPartOfApplicationSet or something similar?

The function only checks if there’s an owner reference pointing to an ApplicationSet, and does not check if rolling sync has been enabled. I understand that the sync-strategy is checked later in the code, but I would argue that the current function name is a bit misleading considering what it actually does.

@nitishfy
Copy link
Member

updatedFix.mov

We are currently hiding that icon. What about the case when it has been enabled and shouldn't be unknown?

@aali309
Copy link
Contributor Author

aali309 commented Aug 21, 2025

updatedFix.mov

We are currently hiding that icon. What about the case when it has been enabled and shouldn't be unknown?

current logic, I believe it's working correctly:
When rolling sync is enabled and status is available: Shows the actual progressive sync status
When rolling sync is enabled but status not yet populated: Shows "Waiting" status (not "Unknown")
When ApplicationSet doesn't use RollingSync strategy: Hides the section entirely (return null)

@aali309
Copy link
Contributor Author

aali309 commented Aug 21, 2025

updatedFix.mov

We are currently hiding that icon. What about the case when it has been enabled and shouldn't be unknown?

current logic, I believe it's working correctly: When rolling sync is enabled and status is available: Shows the actual progressive sync status When rolling sync is enabled but status not yet populated: Shows "Waiting" status (not "Unknown") When ApplicationSet doesn't use RollingSync strategy: Hides the section entirely (return null)

This is when its enabled

Screenshot 2025-08-21 at 2 11 00 PM Screenshot 2025-08-21 at 2 12 56 PM

@aali309 aali309 force-pushed the ProgressiveSyncUnknownInUI branch from 577ea25 to 91247cd Compare August 21, 2025 18:13
@reggie-k
Copy link
Member

@aali309 Could you attach a screenshot of how it looks like when the App is part of a progressive sync but the user has no permissions on the AppSet? I'm asking myself for this case, should we even display the progressive sync status for the App?

@aali309 aali309 force-pushed the ProgressiveSyncUnknownInUI branch from 91247cd to e09721f Compare August 26, 2025 13:31
@aali309
Copy link
Contributor Author

aali309 commented Aug 27, 2025

@aali309 Could you attach a screenshot of how it looks like when the App is part of a progressive sync but the user has no permissions on the AppSet? I'm asking myself for this case, should we even display the progressive sync status for the App?

I think its better to create a follow up PR to close this access denied issue #24225

I was also thinking to have something like this
Screenshot 2025-08-26 at 8 47 13 AM

For user awareness, it informs users that there is progressive sync information available, but they don't have access to it. WDYT?

@reggie-k
Copy link
Member

reggie-k commented Aug 28, 2025

I like this approach, but not sure, from security point if view, that we are not disclosing info that isn't supposed to be disclosed. Would love to hear @crenshaw-dev or @agaudreault 's take on this. I'm adding it to today's contributor agenda meeting for discussion.

@aali309
Copy link
Contributor Author

aali309 commented Aug 28, 2025

I like this approach, but not sure, from security point if view, that we are not disclosing info that isn't supposed to be disclosed. Would love to hear @crenshaw-dev or @agaudreault 's take on this. I'm adding it to today's contributor agenda meeting for discussion.

Thank you @reggie-k , so I guess we are disabling it

@reggie-k
Copy link
Member

@aali309 Please see the summary from today's contributor meeting (the RBAC + docs stuff can go into another PR)
#24190 (comment)

@reggie-k
Copy link
Member

reggie-k commented Aug 28, 2025

I believe we would need the following scenarios tested:

  1. Application page for an app that is part of an AppSet WITH progressive sync and user WITH permissions on the AppSet (either an admin or has explicit permissions) - the panel should be shown
  2. Application page for an app that is part of an AppSet WITH progressive sync and user WITHOUT permissions on the AppSet - the panel should be hidden
  3. Application page for an app that is part of an AppSet WITHOUT progressive sync and user WITH permissions on the AppSet (either an admin or has explicit permissions)- the panel should be hidden
  4. Application page for an app that is part of an AppSet WITHOUT progressive sync and user WITHOUT permissions for the AppSet - the panel should be hidden
  5. Application page for an app that is NOT part of an AppSet - the panel should be hidden

@aali309 aali309 force-pushed the ProgressiveSyncUnknownInUI branch from 5777196 to 1451cee Compare September 4, 2025 16:20
@aali309
Copy link
Contributor Author

aali309 commented Sep 4, 2025

I believe we would need the following scenarios tested:

  1. Application page for an app that is part of an AppSet WITH progressive sync and user WITH permissions on the AppSet (either an admin or has explicit permissions) - the panel should be shown
  2. Application page for an app that is part of an AppSet WITH progressive sync and user WITHOUT permissions on the AppSet - the panel should be hidden
  3. Application page for an app that is part of an AppSet WITHOUT progressive sync and user WITH permissions on the AppSet (either an admin or has explicit permissions)- the panel should be hidden
  4. Application page for an app that is part of an AppSet WITHOUT progressive sync and user WITHOUT permissions for the AppSet - the panel should be hidden
  5. Application page for an app that is NOT part of an AppSet - the panel should be hidden

Tested all these 5 scenarios @reggie-k @agaudreault PTAL.

const appSetRef = application.metadata.ownerReferences.find(ref => ref.kind === 'ApplicationSet');
const isPermissionError = (error: any): boolean => {
const errorText = extractErrorText(error);
return errorText.includes('Failed to load data');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Relying on error text is fragile, could you look into the error object when permissionError occurs to see if something like errorCode or statusCode(403) or error type exists and use that instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I thought initially but here's what I found:

  • The DataLoader component wraps HTTP errors in React elements, so we can't directly access HTTP status codes like error.status or error.statusText.
    Therefore:
    error.status → undefined (not accessible)
    error.statusText → undefined (not accessible)
    error.response → undefined (not accessible)
    error.code → undefined (not accessible)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be better to check for permissions explicitly using can-i, like here:

const logsAllowed = await services.accounts.canI('logs', 'get', application.spec.project + '/' + application.metadata.name);

Showing / hiding logs of pods in the App is done with a similar logic - shown if the user has permissions, hidden otherwise.

Copy link
Member

@ranakan19 ranakan19 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left some comments inline

@aali309 aali309 force-pushed the ProgressiveSyncUnknownInUI branch 4 times, most recently from 6235ef9 to 9afdc12 Compare September 9, 2025 20:00
@aali309
Copy link
Contributor Author

aali309 commented Sep 11, 2025

@reggie-k
I see on the issue that we should also hide the panel when AllAtOnce strategy is enabled? It should only show for RollingSync strategy, and user has permissions?

@aali309 aali309 force-pushed the ProgressiveSyncUnknownInUI branch 2 times, most recently from 710808c to a463e21 Compare September 15, 2025 21:31
@aali309 aali309 force-pushed the ProgressiveSyncUnknownInUI branch from a463e21 to c20ec1d Compare September 17, 2025 15:14
Copy link
Contributor

@keithchong keithchong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@keithchong keithchong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging.

@keithchong keithchong merged commit fbcaf35 into argoproj:master Sep 18, 2025
24 checks passed
@keithchong keithchong added the cherry-pick/3.2 Candidate for cherry picking into the 3.2 release branch label Sep 18, 2025
argo-cd-cherry-pick-bot bot pushed a commit that referenced this pull request Sep 18, 2025
@argo-cd-cherry-pick-bot
Copy link

🍒 Cherry-pick PR created for 3.2: #24641

@argo-cd-cherry-pick-bot
Copy link

🍒 Cherry-pick PR created for 3.1: #24643

aali309 added a commit to aali309/argo-cd that referenced this pull request Sep 18, 2025
jannfis pushed a commit that referenced this pull request Sep 18, 2025
jannfis pushed a commit that referenced this pull request Sep 18, 2025
@aali309 aali309 deleted the ProgressiveSyncUnknownInUI branch October 16, 2025 17:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cherry-pick/3.1 Candidate for cherry picking into the 3.1 release branch cherry-pick/3.2 Candidate for cherry picking into the 3.2 release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ArgoCD UI crashes when Appset Progressive sync is enabled Progress Sync Unknown in UI

7 participants