From 519789226d1888f9a121ed46f42a80409a931f05 Mon Sep 17 00:00:00 2001
From: "claude[bot]" <41898282+claude[bot]@users.noreply.github.com>
Date: Wed, 8 Jul 2026 01:24:12 +0000
Subject: [PATCH] fix(argo): make fuzekeys-sealed self-heal from a failed first
 sync

The fuzekeys-sealed Application was the only app reported OutOfSync/Missing
(conditions null). Its SealedSecret manifests are valid and consistent, but
unlike the sibling fuzekeys-platform app it had no retry policy and no
ServerSideApply:

- On a from-scratch cluster Argo can attempt the first sync before FuzeInfra's
  sealed-secrets controller has registered the bitnami.com/SealedSecret CRD. The
  apply fails, the error lands in .status.operationState (not .status.conditions,
  which explains the empty conditions in the alert), and without a retry backoff
  the app stays latched OutOfSync/Missing until a manual sync. Add a retry block
  mirroring fuzekeys-platform so it self-recovers.
- Add ServerSideApply=true so the large encryptedData blobs don't get a
  client-side last-applied-configuration annotation (262 KiB metadata limit) and
  kubeseal's creationTimestamp: null no longer diffs forever, which would keep
  the app OutOfSync even after the SealedSecrets exist.

prune stays false (never auto-prune secrets); no finalizer is added so deleting
the Application never cascades a delete of the live Secrets.

Co-authored-by: Israel Weinberg <99821070+izzywdev@users.noreply.github.com>
---
 .../argocd/applications/fuzekeys-sealed.yaml  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/deploy/argocd/applications/fuzekeys-sealed.yaml b/deploy/argocd/applications/fuzekeys-sealed.yaml
index 2f7f4c1..c755e34 100644
--- a/deploy/argocd/applications/fuzekeys-sealed.yaml
+++ b/deploy/argocd/applications/fuzekeys-sealed.yaml
@@ -24,3 +24,22 @@ spec:
       selfHeal: true
     syncOptions:
       - CreateNamespace=true
+      # ServerSideApply avoids the client-side last-applied-configuration
+      # annotation on the large encryptedData blobs — that annotation both blows
+      # past the 262 KiB metadata limit and leaves kubeseal's `creationTimestamp:
+      # null` diffing forever, which pins the app OutOfSync even once the
+      # SealedSecrets exist. SSA also matches fuzekeys-platform.
+      - ServerSideApply=true
+    # Parity with fuzekeys-platform: retry a FAILED apply on a backoff. On a
+    # from-scratch cluster Argo can attempt the first sync before FuzeInfra's
+    # sealed-secrets controller has registered the bitnami.com/SealedSecret CRD;
+    # that apply fails ("no matches for kind SealedSecret"), the error lands in
+    # .status.operationState (NOT .status.conditions — hence the empty
+    # conditions in the alert), and without retry the app latches OutOfSync /
+    # Missing until a manual sync. The backoff lets it self-recover.
+    retry:
+      limit: 5
+      backoff:
+        duration: 15s
+        factor: 2
+        maxDuration: 5m