-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Argo CD UI needs hard page refresh to update apps #9247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
If it helps, I also experienced this, but only when using Doesn't seem to happen when using ssl-passthrough mode. I just reused the same TLS certfificate ingress was using, and created it with the name |
Hi @CVanF5 , I tried enabling ssl-passthrough and changing the secret name to argocd-server-tls and haven't set --insecure mode as well, but the issue persist, here's my ingress config in helm values.yaml, |
I can confirm that this issue still exists in ArgoCD v2.6.3 as well. |
Hello, I confirm a hard refresh is also needed with Ingress configuration:
|
Hello, |
Same issue here |
Having the same issue |
Also having the same issue... It's really annoying :-( |
I figured this was happening because argocd ui tries to use grpc stream but not all reverse proxies support it. |
So which reverse proxy do you use and did you manage to resolve the issue? |
Azure Application Gateway and there's no solution other than using a HTTP2 compatible proxy or Argocd providing an UI that doesn't try to call the stream. |
Problem persists! ArgoCD behind a Cloudflare Tunnel and a Traefik Ingress Controller. |
I'm having this issue using Traefik and EKS, are there any steps to troubleshoot or try to resolve this. I feel like this is a really annoying issue. I'm currently using |
I have now ventured to FluxCD because it seems like there is no motion here anymore. And what can I say, so far I am not regretting it. |
Update: enabling http2 on application gateway actually resolved the issue |
I'm using Traefik as proxy. At some point in the past it used to work, but then somehow it stopped. I don't know what I did that lead to this behavior.
Could you elaborate please? Are you talking about Gateway API? |
@HWiese1980 I just enabled this. It seemed enough to make it refresh again. |
@mtrin Thanks for the link! You're on Azure, that's a completely different story for me. I am on a bare-metal K8s cluster with a Traefik ingress controller. I'll have to check whether the cause is the same and if I can enable HTTP2 there too, in case it isn't yet (which I doubt). |
@HWiese1980 I don't grasp too much on that but from what I understand, Traefik would need to accept and translate the stream to http1 or you should have http2 end to end |
Okay, good to know, in case I'll give ArgoCD another try. For now, I am pretty happy with FluxCD too, even though it sadly has no dashboard. |
Think I am hitting the issue |
Argo 2.10.4: the problem persists. In insecure mode, the GUI does not refresh. |
This is really annoying, this is a serious bug as far as I'm concerned it makes the product a lot less usable. And its almost been open for a year with no real responses as to how to try to debug or what the next steps are, or any indication its being looked at. Just more and more people saying they have the issue. Is there anyway we can escalate this? I get that its an open source product but you;ve literally got people saying they are moving to flux b/c of this issue. I'm not expecting an immediate fix, but it would at least be nice to know its being investigated / there will be a fix in the future. |
Hi, we just encountered the same problem and maybe our findings will help some of you
but if we tweak our browser to do
with the correct ingressRoute with gRPC support : apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: argo-cd-ui
spec:
entryPoints:
- websecure
routes:
- match: Host(`argocd.example.com`)
kind: Rule
priority: 10
services:
- name: argocd-server
port: 80
- match: Host(`argocd.example.com`) && Headers(`Content-Type`, `application/grpc`)
kind: Rule
priority: 11
services:
- name: argocd-server
port: 80
scheme: h2c
tls: {} Everything works fine and we don't need to refresh the page anymore |
This PR fixes issue argoproj#9247 where the Argo CD UI requires a hard page refresh to see updates to applications. Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh.
This PR fixes issue argoproj#9247 where the Argo CD UI requires a hard page refresh to see updates to applications. Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh.
This PR fixes issue argoproj#9247 where the Argo CD UI requires a hard page refresh to see updates to applications. Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. Signed-off-by: Marcus Bergo <[email protected]>
This PR fixes issue argoproj#9247 where the Argo CD UI requires a hard page refresh to see updates to applications. Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. Signed-off-by: Marcus Bergo <[email protected]>
This PR fixes issue argoproj#9247 where the Argo CD UI requires a hard page refresh to see updates to applications. Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. Signed-off-by: Marcus Bergo <[email protected]>
Fixes argoproj#9247 Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. This fix addresses a core UI functionality issue and should be considered for cherry-picking into older releases. Signed-off-by: Marcus Bergo <[email protected]>
Fixes argoproj#9247 Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. This fix addresses a core UI functionality issue and should be considered for cherry-picking into older releases. Signed-off-by: Marcus Bergo <[email protected]>
Fixes argoproj#9247 Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. This fix addresses a core UI functionality issue and should be considered for cherry-picking into older releases. Signed-off-by: Marcus Bergo <[email protected]>
@alexmt is this resolved? |
Fixes argoproj#9247 Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. This fix addresses a core UI functionality issue and should be considered for cherry-picking into older releases. Signed-off-by: Marcus Bergo <[email protected]>
Fixes argoproj#9247 Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. This fix addresses a core UI functionality issue and should be considered for cherry-picking into older releases. Signed-off-by: Marcus Bergo <[email protected]>
Fixes argoproj#9247 Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. This fix addresses a core UI functionality issue and should be considered for cherry-picking into older releases. Checklist: - [x] Fixed EventSource error handler in requests.ts - [x] Improved retry logic in applications-service.ts - [x] Enhanced application list loading in applications-list.tsx - [x] Fixed application details page in application-details.tsx - [x] Added comprehensive tests for all modified components - [x] Fixed TypeScript errors and linting issues - [x] Ensured code follows project style guidelines - [x] Verified the fix works correctly in local testing Signed-off-by: Marcus Bergo <[email protected]>
Fixes argoproj#9247 Root Cause: The issue was caused by incorrect error handling in the EventSource connection and improper ordering of RxJS operators. Specifically: 1. The EventSource error handler in requests.ts was incorrectly defined as a function that returns another function, which prevented proper error handling and reconnection when the connection was lost. 2. The RxJS operators in applications-service.ts were not ordered optimally, causing issues with retry behavior and reconnection attempts. 3. The application list loading in applications-list.tsx was mutating the original applications array directly, which could lead to inconsistent state updates. 4. The application details page in application-details.tsx had unnecessary repeat and retry operators that were causing issues with the WebSocket connection. Changes Made: 1. Fixed the EventSource error handler in requests.ts to be a direct function that handles errors properly. 2. Improved the retry logic in applications-service.ts by reordering the RxJS operators and adding a delay parameter to prevent rapid reconnection attempts. 3. Enhanced the application list loading in applications-list.tsx by creating a copy of the applications array and adding better handling for empty update batches. 4. Fixed the application details page in application-details.tsx by removing unnecessary operators and simplifying the stream handling. Added comprehensive tests for all modified components to ensure the fix works correctly and prevent regression. These changes ensure that the UI properly reconnects when the WebSocket connection is lost and that updates are properly propagated to the UI without requiring a hard page refresh. This fix addresses a core UI functionality issue and should be considered for cherry-picking into older releases. Checklist: - [x] Fixed EventSource error handler in requests.ts - [x] Improved retry logic in applications-service.ts - [x] Enhanced application list loading in applications-list.tsx - [x] Fixed application details page in application-details.tsx - [x] Added comprehensive tests for all modified components - [x] Fixed TypeScript errors and linting issues - [x] Ensured code follows project style guidelines - [x] Verified the fix works correctly in local testing Signed-off-by: Marcus Bergo <[email protected]>
@HWiese1980 @reginapizza @alexmt in case this is still an issue, please take a look on #22727 |
Checklist:
argocd version
.Describe the bug
After pulling from the latest argo cd code, I've noticed (as have some other people) that the Argo CD UI does not update responsively. It needs a hard page refresh in order to see the newest changes (see video).
To Reproduce
refresh-ui-error.mp4
Expected behavior
Expected that the applications page would automatically update to have the app I just created.
Version
The text was updated successfully, but these errors were encountered: