ExtraResources works as expected only in local environment

[tiagat]

Hi guys!

What happened?

I encountered a problem where the ExtraResources and getExtraResources function only work in a local environment when executing the crosplain render command.
The same composite does not work in a real Kubernetes cluster.

How can we reproduce it?

SandBox:

definition.yaml

apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
  name: democlaims.example.io
spec:
  scope: Namespaced
  group: example.io
  names:
    kind: DemoClaim
    plural: democlaims
    singular: democlaim
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            status:
              type: object
              properties:
                debug:
                  type: string
                  nullable: true

composition.yaml

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: democlaim
spec:
  compositeTypeRef:
    apiVersion: example.io/v1alpha1
    kind: DemoClaim
  mode: Pipeline
  pipeline:
    - step: extra-resources
      functionRef:
        name: crossplane-contrib-function-go-templating
      input:
        apiVersion: gotemplating.fn.crossplane.io/v1beta1
        kind: GoTemplate
        source: Inline
        inline:
          template: |
            apiVersion: meta.gotemplating.fn.crossplane.io/v1alpha1
            kind: ExtraResources
            requirements:
              config:
                apiVersion: v1
                kind: ConfigMap
                matchName: dummy-config
            ---
            {{ $debug := index . "extraResources" }}
            apiVersion: example.io/v1alpha1
            kind: DemoClaim
            status:
              debug: |
                {{ $debug | toJson }}    
    - step: automatically-detect-ready-composed-resources
      functionRef:
        name: crossplane-contrib-function-auto-ready
  

extraresources.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: dummy-config
data:
  debug: "dummy"

functions.yaml

apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
  name: crossplane-contrib-function-go-templating
spec:
  package: xpkg.crossplane.io/crossplane-contrib/function-go-templating:v0.11.3
---
apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
  name: crossplane-contrib-function-auto-ready
spec:
  package: xpkg.crossplane.io/crossplane-contrib/function-auto-ready:v0.5.2

xr.yaml

apiVersion: example.io/v1alpha1
kind: DemoClaim
metadata:
  name: dummy-claim
  namespace: default
spec: {}

on local machine I can see entire required object

$ crossplane render xr.yaml composition.yaml functions.yaml -e extraresources.yaml

---
apiVersion: example.io/v1alpha1
kind: DemoClaim
metadata:
  name: dummy-claim
  namespace: default
status:
  conditions:
  - lastTransitionTime: "2024-01-01T00:00:00Z"
    reason: Available
    status: "True"
    type: Ready
  debug: "{\"config\":{\"items\":[{\"resource\":{\"apiVersion\":\"v1\",\"data\":{\"debug\":\"dummy\"},\"kind\":\"ConfigMap\",\"metadata\":{\"name\":\"dummy-config\"}}}]}}
    \   \n"

But in a real Kubernetes cluster:

apiVersion: example.io/v1alpha1
kind: DemoClaim
metadata:
  ...
status:
  conditions:
    ...
debug: |
    {"config":{}}  

What environment did it happen in?

Crossplain

chart: crossplane
repoURL: "https://charts.crossplane.io/stable"
targetRevision: 2.1.1

Function

apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
  name: crossplane-contrib-function-go-templating
spec:
  package: xpkg.crossplane.io/crossplane-contrib/function-go-templating:v0.11.3

Kubernetes

Client Version: v1.35.0
Kustomize Version: v5.7.1
Server Version: v1.33.4

$ k get xrd           
NAME                          ESTABLISHED   OFFERED   AGE
democlaims.example.io         True                    30m

$ k get composition      
NAME             XR-KIND          XR-APIVERSION          AGE
democlaim        DemoClaim        example.io/v1alpha1    29m

$ k get DemoClaim dummy-claim
NAME          SYNCED   READY   COMPOSITION   AGE
dummy-claim   True     True    democlaim     28m

[bobh66]

This might be related to #537

[stempher]

use matchLabels (#501)

[tiagat-goreel]

nope. Looks like the same behavior, works only in the local environment.
In real Kubernetes or using UXP - null instead of the requested resource

[bobh66]

ConfigMaps are namespaced so you need to tell Crossplane what namespace to use when looking for the resource. Maybe it defaults to the local namespace for v2 XRs, I haven't tried that. Regardless I believe it requires a fix that is on the main branch and should be released this weekend. The reason it works in render is that the extra resources are provided directly to the template up front and don't require a second call to the function. Generally you want to request the extra resources and then check to see if they have been provided before rendering anything.

[giepa]

We're experiencing the same issue with function-go-templating v0.12.0 (embedded via up project build) on Crossplane v2.2.1.

Setup:

• Embedded go-templating function emits kind: ExtraResources to fetch a ConfigMap by label (crossplane.io/composite: <name>)
• The ConfigMap exists in the same namespace as the XR
• Composition pipeline: embedded function → function-auto-ready (no function-extra-resources)

Behavior:

• up composition render works perfectly (context is populated, resources render correctly)
• On a real cluster, the function is called and returns requirements in the RunFunctionResponse, but Crossplane never fulfills them
• The context (apiextensions.crossplane.io/extra-resources) is always empty on every reconcile
• No errors in function logs or Crossplane core logs — completely silent failure
• Function consistently renders count:3 (requirements + status + connection details) instead of count:5 (with Role + Grant that depend on the extra resources data)

What we tried:

• With and without namespace in the ExtraResources requirement (PR Handle namespaced ExtraResources properly #537 fix)
• Restarting Crossplane pods
• Forcing reconciliation via spec changes
• Verified the ConfigMap exists with correct labels

Workaround we're considering:
Adding crossplane-contrib/function-extra-resources as a separate pipeline step to handle the fetching, rather than relying on the native ExtraResources support in function-go-templating.