fuzefront-applications: 470 restarts (up from 28) — diagnose as its own defect, not as collateral of #750

[izzywdev]

@claude

fuzefront-applications is in a restart storm in prod: 470 restarts. Please diagnose it as its own defect, from the container's own crash output.

Read this first — how this relates to #750 and #831

fuzefront-applications is mentioned in #750, but only in passing, as collateral: that issue's body lists it as "fuzefront-applications (Error, 28 restarts)" among other pods failing to roll out, while #750's title, root cause, and acceptance criteria are all about fuzefront-backend and the migration-015/022 root-org fault. The literal #750 defect was fixed by #751, and the reintroduced sibling in migration 026 by #831.

So the open question this issue exists to answer: is fuzefront-applications still crashing for a reason of its own, or is it downstream of the unresolved root-org repoint/reparent decision in #750?

Two facts say it deserves its own diagnosis rather than being folded into #750:

• It has gone from 28 restarts (measured 2026-08-20 in Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750) to 470 (measured 2026-09-01) — it kept crashing across the entire period in which fix: unblock the stalled prod rollout — root-org FK violation (#750) and the @fuzefront/shared subpath crash #751 and fix(db): migration 026 reintroduced the #750 root-org crashloop #831 landed.
• The fix(db): migration 026 reintroduced the #750 root-org crashloop #831 comment on Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750 notes a guard fix for "applications-services 011" — i.e. this component has its own migration-guard defect of the same class, separate from backend's 026. Confirm whether that fix actually reached the running image, and whether 011 is the current failure or merely a past one.

Do not close this as a duplicate of #750 without evidence. If the evidence shows it genuinely is the same root-org blocker, say so explicitly here with the exit code and logs that demonstrate it, and link it — that is a valid outcome, but it must be demonstrated, not assumed.

What was measured

Pod	Namespace	Restarts	Measured
fuzefront-applications	fuzefront	470	2026-09-01, pre-outage

Ownership is established by argocd/projects/fuzefront.yaml in FuzeInfra, whose sourceRepos is exactly https://github.com/izzywdev/FuzeFront.git, with destinations restricted to the fuzefront namespace. FuzeInfra runs the Argo instance and the cluster; it does not edit consumer charts or application code.

Important: the cluster is currently unreachable

The prod k3s API is refusing connections on 6443 as of 2026-09-02. The 470 figure was measured on 2026-09-01, before the outage. Do not treat a failure to reach the cluster today as evidence the problem is gone, and do not wait idle for it — the source-level work below can start now.

What to do

Diagnose from the container, not from the infrastructure.

1. The container's exit code and termination reason (lastState.terminated.reason / .exitCode).
2. The container's own stdout/stderr from the crashing boot — the previous container's logs, not the current one's.
3. Whether it dies before or after binding its port, and specifically whether the fatal line is a migration guard throwing on an absent ROOT_ORG_ID (the Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750/fix(db): migration 026 reintroduced the #750 root-org crashloop #831 class) or something unrelated.
4. Whether the deployed image actually contains the applications-services 011 guard fix, or predates it.

Do NOT

• Do not kubectl patch or kubectl edit the live Deployment. Prod is GitOps and Argo selfHeal reverts out-of-band changes within seconds.
• Do not mask the crash by widening probe thresholds, adding startup retries, or increasing backoff.
• Do not decide the root-org repoint-or-reparent question here. Per the maintainer's own comment on Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750 that remains their call; this issue is diagnosis and, if the cause is independent, a fix.

Acceptance criteria

1. The crash cause for fuzefront-applications specifically is identified from its own exit code and previous-boot logs, and written down here.
2. It is stated explicitly, with evidence, whether this is independent of Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750 or downstream of it.
3. If independent: a fix lands as a merged PR that Argo syncs.
4. fuzefront-applications reaches a stable Running 1/1 — stable meaning the restart count stops increasing over a sustained observation window. A restart counter resets when a pod is replaced; a fresh low number is not proof of a fix.
5. Verified against the live cluster with FuzeInfra's cluster-query workflow (repository_dispatch type cluster-query) — see docs/consuming-repos/CLUSTER_QUERY.md in FuzeInfra. Do not report done from a manifest diff alone. Blocked until the prod cluster is reachable again; do the source work first.

STATE:

• Why: fuzefront-applications at 470 restarts, up from 28 on 2026-08-20, across the window in which fix: unblock the stalled prod rollout — root-org FK violation (#750) and the @fuzefront/shared subpath crash #751 and fix(db): migration 026 reintroduced the #750 root-org crashloop #831 landed. Treated as collateral in Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750 and never diagnosed on its own terms.
• Done: Restart count measured 2026-09-01 pre-outage. Ownership confirmed via FuzeInfra argocd/projects/fuzefront.yaml sourceRepos. Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750/fix: unblock the stalled prod rollout — root-org FK violation (#750) and the @fuzefront/shared subpath crash #751/fix(db): migration 026 reintroduced the #750 root-org crashloop #831 history reviewed; confirmed Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750's root cause and acceptance criteria are about fuzefront-backend, and that a separate applications-services 011 guard fix is referenced in fix(db): migration 026 reintroduced the #750 root-org crashloop #831's comment.
• Remains: All acceptance criteria. The crash cause is not yet known — no exit code and no container logs have been read. Nothing has been changed in this repo or in the cluster.
• Decisions made: This is diagnosed as its own defect; a duplicate-of-Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750 conclusion is permitted only with evidence. The root-org repoint/reparent decision stays with the maintainer and is out of scope here.
• Open: The actual crash cause; whether it is independent of Backend CrashLoopBackOff in prod: migration 015 infers "root org present" from a slug conflict, then FK-violates #750; whether the running image carries the applications-services 011 guard fix.
• Blocked on: Live verification only — the prod k3s API is refusing connections on 6443 as of 2026-09-02.
• Filed by: platform-governance (FuzeInfra), as cross-repo @claude delegation. Nothing in this repo was edited.

[claude]

Claude finished @izzywdev's task in 0s —— View job

---

I'll analyze this and get back to you.