argo-cd: ArgoCD Server - main.js returns 404 Error

Checklist:

  • I’ve searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
  • I’ve included steps to reproduce the bug.
  • I’ve pasted the output of argocd version.

Describe the bug

After updating to version v2.5.2, developers started getting a 404 error for the main.***.js request. I found that ArgoCD Server generates a different hash for the main.js file.

To Reproduce

  1. Deploy ArgoCD v2.5.2 with several server replicas.

Expected behavior

ArgoCD Server returns a main.js file without a 404 error.

Screenshots

image image image

Version

argocd-server: v2.5.2+148d8da
  BuildDate: 2022-11-07T16:43:02Z
  GitCommit: 148d8da7a996f6c9f4d102fdd8e688c2ff3fd8c7
  GitTreeState: clean
  GoVersion: go1.18.8
  Compiler: gc
  Platform: linux/arm64
  Kustomize Version: v4.5.7 2022-08-02T16:35:54Z
  Helm Version: v3.10.1+g9f88ccb
  Kubectl Version: v0.24.2
  Jsonnet Version: v0.18.0

Logs

Paste any relevant application logs here.

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 2
  • Comments: 15 (1 by maintainers)

Most upvoted comments

@jessesuen @azmansalleh I found out why it happens. When the ArgoCD Server pod is running on the amd64 node it generates main.d73b393b850229804000.js and when it running on arm64 - main.4506baf321b40cb8926e.js. if the browser will ask amd main.js file from arm pod we will get 404.

@sidewinder12s what if we just start by loading the architecture info at runtime from the API server instead of building it into the JS bundle? The platform info is available on the api/version endpoint.

This doesn’t solve the issue of non-determinism in response origin (still gotta pin architecture as described above), but it does solve the 404s by avoiding architecture-specific bundles. It’s a nice easy incremental improvement.

Ya I think that’d solve the biggest user facing issue.

@jessesuen could you reopen this issue?

I can also confirm we just moved to mixed arch set of nodes and will randomly run into this as 1 server pod is ARM, 1 is x86. I am still on ArgoCD 2.6.x, so can’t confirm if a newer version of ArgoCD still has this issue just yet.

@loafoe I am running the argocd server pods only on one platform (arm64). To do it I use node selectors