Repository navigation
Extension API server returns typed Application instead of unstructured for server-side apply #1673
Description
Description
When using server-side apply (kubectl apply --server-side) against Cozystack extension API resources (Kubernetes, Tenant, Postgres, NATS, Redis, etc.), the API server returns *v1alpha1.Application typed objects instead of unstructured objects, causing the following error:
Error from server: expected unstructured.Unstructured object, got *v1alpha1.Application
This affects all resources served by the cozystack-api extension API server (v1alpha1.apps.cozystack.io).
To Reproduce
# From a directory containing Cozystack CRDs (Kubernetes, Tenant, Postgres, etc.)
kustomize build . | kubectl apply --server-side --dry-run=server -f-Expected Behavior
Server-side apply should return unstructured objects, allowing the apply to succeed.
Actual Behavior
The extension API server returns typed *v1alpha1.Application objects instead of unstructured objects, causing server-side apply to fail.
Impact
Flux CD kustomize-controller cannot reconcile any Cozystack CRDs.
Flux uses server-side apply by default. Any Kustomization containing Cozystack resources (Kubernetes, Tenant, Postgres, NATS, Redis, etc.) fails with:
Kubernetes/tenant-dmz/prod dry-run failed: expected unstructured.Unstructured object, got *v1alpha1.Application
Workaround
None known. Client-side apply (kubectl apply without --server-side) works correctly, but Flux does not support switching to client-side apply.
Environment
- Cozystack version: v0.38.0, v0.38.1
- Last working version: v0.37.6
- Flux kustomize-controller: v1.6.1
- Kubernetes: v1.33
Additional Context
The v0.38.0 release notes mention "fixed API representation of dynamic list kinds for better compatibility" - this change may be related to the regression.
Regular dry-run validation works:
kubectl apply --dry-run=server -f manifest.yaml # Works
kubectl apply --server-side --dry-run=server -f manifest.yaml # Fails
Activity
dosubot commentedon Nov 29, 2025
Hi Isaiah Olson (@insignia96)! I'm Dosu and I’m helping the cozystack team.
This regression is caused by how the Cozystack API server registers dynamic types and implements the Typer interface. In v0.38.0+, all dynamic Application kinds are registered as Go structs (e.g.,
*v1alpha1.Application) under the same key, so the Typer defaults to the first registered GroupVersionKind. Server-side apply expects unstructured objects, but the API server returns typed objects, leading to the error you see. Only a correctly formed&unstructured.Unstructured{}circumvents this logic, and evenUnstructuredListis not accepted—itemsmust be set directly on the underlying map for lists. This change was introduced as part of the "dynamic list kind" compatibility fix (PR #1630).The REST storage does convert responses to unstructured objects, but the scheme's dynamic registration allows the generic API server to coerce responses into typed structs during server-side apply, which breaks Flux and similar workflows. There is currently no configuration workaround; resolving this requires changes to how dynamic types are registered and how list responses are constructed (source, source).
If you need server-side apply compatibility, the API server must always return unstructured objects for these resources, and list responses must set the
itemskey directly on the map, not use typed lists. This is a code-level fix.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
kvaps commentedon Nov 29, 2025
Hey Isaiah Olson (@insignia96) thanks for the report, I'll take a look at this
kvaps commentedon Dec 9, 2025
Hey, thank you. I think this was fixed by #1630 and released in
v0.38.2Could you please confirm?
insignia96 commentedon Dec 10, 2025
This issue persisted for me in v0.38.2 but was fixed after building cozystack-api based on PR #1679
kvaps commentedon Dec 10, 2025
Thank you!