Add Kind filter to EnqueueRequestForProviderConfig

[jakubramut]

Description of your changes

Adds an optional Kind field to EnqueueRequestForProviderConfig that allows controllers to filter ProviderConfigUsage events by the referenced ProviderConfig kind.

Why this is needed:
When a provider has multiple ProviderConfig types (e.g., namespaced ProviderConfig and cluster-scoped ClusterProviderConfig) that share the same ProviderConfigUsage resource, both controllers receive all events. This causes the wrong controller to attempt lookups and log spurious errors like:
cannot get ProviderConfig... ProviderConfig.azuread.m.upbound.io \"name\" not found
even when the resource correctly references a ClusterProviderConfig.

How it works

• If Kind is empty - no changes (backward compatible)
• If Kind is set - only matching events
• Cluster-scoped kinds omit namespace from the reconcile request

How I tested
Based on https://github.com/crossplane-contrib/provider-upjet-azuread using a go.mod replace

1. Applied resources as in [Bug]: Incorrect attempt to look up ProviderConfig crossplane-contrib/provider-upjet-azuread#267
2. Before: Debug logs showing failed ProviderConfig lookups
3. After: No more invalid logs, controllers only process their respective kinds

Related provider PR will follow once this change is released.

Fixes: crossplane-contrib/provider-upjet-azuread#267

I have:

• Read and followed Crossplane's contribution process.
• Run earthly +reviewable to ensure this PR is ready for review.
  No, but I run:

  go test ./pkg/resource -run TestAddProviderConfig
  go vet ./pkg/resource
  golangci-lint run ./pkg/resource
  

• Added or updated unit tests.
• Linked a PR or a docs tracking issue to document this change.
• [] Added backport release-x.y labels to auto-backport this PR.
  Cannot do it, but ready do be added.

Need help with this checklist? See the cheat sheet.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds Kind field to EnqueueRequestForProviderConfig for filtering by resource kind; converts addProviderConfig from package-level function to instance method; implements cluster-aware enqueue logic that omits namespace for cluster-scoped references; maintains backward compatibility with empty Kind defaults.

Changes

Cohort / File(s)	Summary
Core Handler Logic pkg/resource/enqueue_handlers.go	Introduces Kind field to EnqueueRequestForProviderConfig struct; converts addProviderConfig to instance method; adds cluster-aware enqueue logic that omits namespace when Kind starts with "Cluster"; implements Kind-based filtering with "ProviderConfig" as default; delegates all handlers to instance method instead of package function.
Test Coverage pkg/resource/enqueue_handlers_test.go	Refactors test structure to initialize handler per test case; renames existing test case; adds four new test cases validating cluster-scoped behavior (ClusterScopedProviderConfigOmitsNamespace), Kind matching (KindFilterMatchesKind, KindFilterSkipsNonMatchingKind), and default Kind behavior (EmptyRefKindDefaultsToProviderConfig).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding a Kind filter to EnqueueRequestForProviderConfig.
Description check	✅ Passed	The description is well-detailed and directly related to the changeset, explaining the motivation, implementation approach, and testing methodology.
Linked Issues check	✅ Passed	The PR successfully addresses the linked issue #267 by adding Kind filtering to prevent incorrect ProviderConfig lookups when cluster-scoped variants exist.
Out of Scope Changes check	✅ Passed	All changes are directly aligned with the stated objective of adding Kind-based filtering to EnqueueRequestForProviderConfig with appropriate test updates.
Breaking Changes	✅ Passed	The PR introduces no breaking changes to the exported public API. The Kind field is additive and non-breaking. The addProviderConfig function remains unexported, and behavior changes represent backward-compatible bug fixes.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@pkg/resource/enqueue_handlers.go`:
- Around line 73-82: Default an empty ProviderConfigReference kind to
"ProviderConfig" before applying the kind filter and cluster-scope detection:
after obtaining ref via pcr.GetProviderConfigReference() set a localKind =
ref.Kind (or "ProviderConfig" when ref.Kind == "") and then use that localKind
for the comparison against e.Kind and for the strings.HasPrefix(..., "Cluster")
check so events aren't dropped when ref.Kind is omitted; update the comparisons
around e.Kind, strings.HasPrefix(ref.Kind, "Cluster"), and the reconcile.Request
construction to reference the normalized localKind.

[ezgidemirel]

Thanks for the PR @jakubramut! It solves the issue in a straightforward way with a backward-compatible API change.

[jakubramut]

Thank you for a review @ezgidemirel.
I saw the CI/protobuf-schemas check failed, can I somehow fix it or it's not related to my change?

[ezgidemirel]

Thank you for a review @ezgidemirel. I saw the CI/protobuf-schemas check failed, can I somehow fix it or it's not related to my change?

Hi @jakubramut, in main we recently updated ci.yaml and removed the following lines:

        with:
          input: apis

I suspect this change is causing the CI/protobuf-schemas failure you’re seeing. Could you please rebase your PR on top of main and see if that resolves it?

[adamwg]

lgtm