Secrets not found errors on the applications page

[al-lac]

Describe the bug

In the Applications page we get a lot of these errors on top:
get helmrelease inventory: secrets "sh.helm.release.v1.grafana-agent-logs.v7" not found

These secrets are not there anymore, but i am not sure why the gitops applications shows these errors as everything is ok.

Environment

• Weave-Gitops Version: 0.27.0
• Flux Version: 2.0.1
• Kubernetes version: 1.26.5

To Reproduce
Steps to reproduce the behavior:

1. Have some secrets that have been deleted.
2. Go to the Applications page in gitops
3. See the errors on top

Expected behavior

No errors should be shown / deleted secrets should be ignored.

Actual Behavior

Errors are shown. See screenshot.

Additional Context (screenshots, logs, etc)

[foot]

Thanks for the report!

We read that secret to show what resources were generated from the HelmRelease in the UI which can be handy.

It's a bit strange they are gone, do you know if they were manually removed or not created for some reason? Perhaps you could share the HelmRelease CR for external-secrets or grafana-agent-logs and I can have a go repro'ing?

If there is a clear use case for not having the secrets, perhaps using a diff storage backend? (not sure if this is configurable via flux though), we could definitely remove the errors that they are missing.

[al-lac]

Hey!

Ok I know looked into it and probably found out why the interface is showing these errors.

We have a remote cluster where those secrets are stored. So those secrets do not exist in the namespace where gitops is looking. They exist on the remote cluster.
Not sure if it is possible to configure gitops to look for the secrets on a different cluster.

An option to disable the errors would be nice, as they are filling up the top of the application view.

[foot]

Ah hah, good one. The HelmRelease has a spec.kubeConfig set?

[al-lac]

Yes, that is set 👍

[foot]

Yes, so thats a bit of a bug I would say.

• Quick fix: do not try and read this secret if spec.kubeConfig set.
• Longer term: try and read the secret from the remote cluster? Would need quite a bit of thought.

Related: #3888, in which we would try and read other interesting information out that secret, but which not be possible if the secret is on another cluster for now.

[al-lac]

Yeah, a quick fix to get rid of the errors would be nice! At least some option that can be set in the config.

[chadswen]

We've been running into this too. We are heavy users of spec.kubeConfig, and at our scale this results in hundreds of the Error alert boxes at the top of the Applications page. I would really appreciate the proposed quick fix as well. Thanks!

[al-lac]

@foot where was this solved? Any commit id / pull request that fixed this?

[foot]

Good catch!

• App page secrets error #4021
• Implement style updates to Alert #4039