Schema not found for some CRDs

[manojsid]

What happened?

we've noticed something odd on the ResourceGraph side. Even though the cluster includes the AccessEntry CRD and it works fine, we're still seeing the error below.

We also tried triggering this CRD independently, and it works with plain YAML. But when we run the same template through the function inside the composition, we hit this error. Any suggestions on what might be causing this?

cannot compose resources: pipeline step "kro-run" returned a fatal result: cannot create resource graph: failed to build resource "entryaccess": failed to get schema for resource entryaccess: cannot resolve eks.aws.m.upbound.io/v1beta1, Kind=AccessEntry: schema not found

How can we reproduce it?

Crossplane Upbound controller - UXP Version 2.1.4-up.2
Aws EKS upbound provider - v2.4.0
Function-kro = v0.3.0

Create a composition with function-kro and try to deploy the AccessEntry CRD

[jonasz-lasut]

Hi @manojsid, thanks for the detailed repro info - I tracked this down.

Root cause (confirmed at source): UXP 2.1.4-up.2 embeds Crossplane v2.1.4, which predates v2.2.0 - the release that introduced the required_schemas capability (CAPABILITY_REQUIRED_SCHEMAS). Since your Crossplane doesn't advertise that capability, function-kro falls back to resolving schemas from CRDs via required_resources (fn.go's requireSchemas/buildResolverFromCRDs).

That fallback path guesses the CRD's Kubernetes object name with naive pluralization:

MatchName: strings.ToLower(gvk.Kind + "s." + gvk.Group)

For Kind: AccessEntry that computes accessentrys.eks.aws.m.upbound.io - but the real CRD shipped by provider-aws-eks is named accessentries.eks.aws.m.upbound.io (correct English plural, "y" → "ies"). The name lookup misses, function-kro logs it as "CRD unavailable" and treats the resource as if it has no CRD at all, so schema resolution for AccessEntry falls through to the built-in-Kubernetes-types-only resolver - producing the schema not found error you're seeing.

That also explains the rest of what you saw: plain kubectl apply works because it doesn't go through this guessed-name lookup, and reinstalling the CRD didn't help because the CRD was never missing - function-kro was just asking Crossplane for the wrong object name.

Fix: replace the naive Kind + "s" guess with flect.Pluralize (the same library Kubernetes codegen tooling itself uses for CRD plurals). I have this fixed and covered by a regression test locally, and will open a PR shortly.

Workaround until the fix ships: upgrade Crossplane/UXP to >= 2.2.0. On that path function-kro requests schemas directly by GVK via required_schemas and never constructs a guessed CRD name, so this bug doesn't apply.