CustomResourceGate reconcilers should filter by owned CRDs

[bobh66]

What happened?

Providers are getting a lot of unnecessary debug log messages from the CustomResourceGate reconciler which is reconciling ALL CRDs instead of just the CRDs that the provider owns and is responsible for.
This is wasting CPU, memory and cluttering logs with useless messages.

How can we reproduce it?

Look at the debug logs for the latest provider-helm when provider-family-aws providers are also installed:

2026-01-28T02:53:06.074Z	DEBUG	provider-helm	gvk is ready	{"gvk": "autoscaling.aws.upbound.io/v1beta1, Kind=AutoscalingGroup"}
2026-01-28T02:53:06.074Z	DEBUG	provider-helm	gvk is ready	{"gvk": "autoscaling.aws.upbound.io/v1beta2, Kind=AutoscalingGroup"}
2026-01-28T02:53:06.074Z	DEBUG	provider-helm	gvk is ready	{"gvk": "autoscaling.aws.upbound.io/v1beta3, Kind=AutoscalingGroup"}
2026-01-28T02:53:06.075Z	DEBUG	provider-helm	gvk is ready	{"gvk": "autoscaling.aws.upbound.io/v1beta1, Kind=Notification"}
2026-01-28T02:53:06.076Z	DEBUG	provider-helm	gvk is ready	{"gvk": "ec2.aws.upbound.io/v1beta1, Kind=TransitGatewayMulticastDomainAssociation"}
2026-01-28T02:53:06.076Z	DEBUG	provider-helm	gvk is ready	{"gvk": "docdb.aws.upbound.io/v1beta1, Kind=ClusterSnapshot"}
2026-01-28T02:53:06.077Z	DEBUG	provider-helm	gvk is ready	{"gvk": "ec2.aws.upbound.io/v1beta1, Kind=VPCPeeringConnectionOptions"}
2026-01-28T02:53:06.077Z	DEBUG	provider-helm	gvk is ready	{"gvk": "ec2.aws.upbound.io/v1beta2, Kind=VPCPeeringConnectionOptions"}
2026-01-28T02:53:06.078Z	DEBUG	provider-helm	gvk is ready	{"gvk": "kubernetes.crossplane.io/v1alpha1, Kind=ObservedObjectCollection"}
2026-01-28T02:53:06.078Z	DEBUG	provider-helm	gvk is ready	{"gvk": "iam.aws.upbound.io/v1beta1, Kind=SAMLProvider"}
2026-01-28T02:53:06.078Z	DEBUG	provider-helm	gvk is ready	{"gvk": "cloudwatchevents.aws.upbound.io/v1beta1, Kind=BusPolicy"}
2026-01-28T02:53:06.079Z	DEBUG	provider-helm	gvk is ready	{"gvk": "s3.aws.upbound.io/v1beta1, Kind=BucketCorsConfiguration"}
2026-01-28T02:53:06.080Z	DEBUG	provider-helm	gvk is ready	{"gvk": "lambda.aws.upbound.io/v1beta1, Kind=FunctionEventInvokeConfig"}
2026-01-28T02:53:06.080Z	DEBUG	provider-helm	gvk is ready	{"gvk": "lambda.aws.upbound.io/v1beta2, Kind=FunctionEventInvokeConfig"}

What environment did it happen in?

Crossplane version: 2.1.3

[SatabdiG]

Hi, I'm interested in working on this. I am part of the team that maintains SAP's BTP and CF providers. I was looking to contribute to the core runtime, and this bug seems interesting to me.

From an initial read of the code, my plan would be to add a predicate filter to the CRD watch so the reconciler only enqueues events for CRDs it owns — likely using an owner label selector. Please let me know if there are any constraints or prior context I may be missing. Also, if there are better approaches.

Let me know if this is still up for grabs!

[SatabdiG]

Hi, I have been investigating this issue and wanted to share my findings before proceeding. I haven't found any trivial fix for the issue.

The Bug Location
The bug seems to be located in setup.go — .For(&apiextensionsv1.CustomResourceDefinition{}) has no predicate, so the reconciler fires for every CRD in the cluster regardless of ownership.

I considered the following approaches:
Option 1 - Pass groups explicitly to Setup(): Add a Groups []string field to controller.Options and use it to build a predicate in Setup(). Non-breaking, works timing-wise. Problem: requires every provider author to explicitly set Groups or the bug silently persists. Incomplete adoption means incomplete fix.
Option 2 - Derive groups from the gate via Conditions() : Add a Conditions() method to the concrete gate.Gate[T] and use a local type assertion in setup.go to avoid touching the public Gate interface. Problem: customresourcesgate.Setup() seems to be called before SetupGated() registers Controllers, so the gate is empty when' Setup() ' runs and returns nothing. The Predicate wouldn't get built.

Both approaches have fundamental problems, and I wanted to surface my concerns before proceeding. Maybe there is a solution I haven't considered?

[bobh66]

Thanks for the investigation @SatabdiG !

While I agree that option 2 would be a better developer experience, I think option 1 is still viable. The upjet-based providers can be fixed upstream in code generation, and other providers can be fixed manually as needed. The most popular providers (helm, kubernetes) will get fixed and others can be updated as people decide they don't want to see those messages anymore.

[SatabdiG]

Thanks @bobh66, I'll get started with Option 1.

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[bobh66]

/fresh

[github-actions]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[bobh66]

/fresh