ArgoCD unhealthy: fuzekeys-sealed (Missing/OutOfSync)

[izzywdev]

@claude ArgoCD reports this repo's app fuzekeys-sealed unhealthy on the shared FuzeInfra cluster.

• sync: OutOfSync
• health: Missing
• conditions (the actual error):

null

FuzeInfra runs the Argo instance but does not edit consumer charts. Please diagnose from this repo's deploy manifests (Helm/kustomize/Argo Application) and open a fix PR. Common causes: a values/kustomize render error (Unknown/ComparisonError), an image pull secret / tag issue (Degraded ImagePullBackOff), or drift (OutOfSync).

[claude]

Claude finished @izzywdev's task in 6m 2s —— View job • claude/issue-35-20260708-0118 • Create PR ➔

---

ArgoCD autofix: fuzekeys-sealed (OutOfSync / Missing)

• Gather context — read deploy/argocd/** manifests + Helm chart + seal workflow
• Diagnose root cause of OutOfSync / Missing
• Implement fix
• Commit, push & open PR

---

Diagnosis

I reviewed every deploy manifest that feeds the fuzekeys-sealed app. The SealedSecret content is correct and consistent — so this is not a render/values error:

• deploy/argocd/sealed/{fuzekeys-secrets,fuzekeys-tokenizer-secrets,ghcr-pull-secret}.yaml all target namespace: fuzekeys, matching the seal workflow's strict-scope kubectl create secret -n fuzekeys and the chart's references (secrets.existingSecret: fuzekeys-secrets, imagePullSecrets: ghcr-pull-secret).
• The AppProject allows the fuzekeys destination; CreateNamespace=true is set.

The telling signal: fuzekeys-sealed is the only app flagged, and conditions is null. Missing means the SealedSecret objects were never materialized in-cluster (not a decryption failure — that would show Synced/Degraded). The one thing unique to this app is that it applies bitnami.com/SealedSecret CRs, and it differs from the healthy fuzekeys-platform app by having no retry policy and no ServerSideApply.

On a from-scratch cluster, Argo can attempt the sealed app's first sync before FuzeInfra's sealed-secrets controller has registered the SealedSecret CRD. That apply fails (no matches for kind SealedSecret), the error lands in .status.operationState — not .status.conditions, which is exactly why the alert's conditions is null — and with no retry backoff the app latches OutOfSync/Missing until someone syncs by hand.

Fix (deploy/argocd/applications/fuzekeys-sealed.yaml)

Brought the sealed app to parity with the working platform app:

• retry backoff (limit 5, 15s→5m) so a transient first-sync apply failure (e.g. CRD registered moments later) self-recovers instead of getting stuck.
• ServerSideApply=true so the large encryptedData blobs don't get a client-side last-applied-configuration annotation (262 KiB metadata cap) and kubeseal's creationTimestamp: null stops diffing forever — which would otherwise keep the app OutOfSync even after the Secrets exist.
• Kept prune: false and added no finalizer, so the live Secrets are never cascade-deleted.

⚠️ FuzeInfra-side prerequisite (delegated — cannot be fixed from this repo)

If fuzekeys-sealed stays Missing after this merges, the root cause is cluster-side and owned by FuzeInfra: verify the sealed-secrets controller + sealedsecrets.bitnami.com CRD are installed and that the controller's active key matches the public cert the seal workflow pulls from https://sealed-secrets.prod.fuzefront.com/v1/cert.pem. Per CLAUDE.md, infra changes are delegated to FuzeInfra via @claude — this repo only commits ciphertext.

Note: helm/python/lint tooling weren't in the sandbox allowlist, so validation here is by direct manifest review (all Argo/sealed YAML read cleanly). The deploy-platform.yml CI gate will run helm lint/kubeconform/actionlint on the PR.

· branch claude/issue-35-20260708-0118