fix: use v1alpha2 APIBindings informer in DynamicRESTMapper HasSynced check

[maxpain]

Problem

The DynamicTypesController is instantiated with a v1alpha2 APIBindings informer:

dynamicTypesController, err := dynamicrestmapper.NewDynamicTypesController(ctx, s.completedConfig.DynamicRESTMapper,
    s.ApiExtensionsSharedInformerFactory.Apiextensions().V1().CustomResourceDefinitions(),
    s.KcpSharedInformerFactory.Apis().V1alpha2().APIBindings(),  // ← v1alpha2
    ...
)

But the HasSynced wait function checks the v1alpha1 informer:

return s.KcpSharedInformerFactory.Apis().V1alpha1().APIBindings().Informer().HasSynced() && // ← v1alpha1

Since the SharedInformerFactory creates separate informers per API version (keyed by reflect.Type), and factory.Start() only starts previously registered informers, the sequence is:

1. Controller registration calls V1alpha2().APIBindings() → registers v1alpha2 informer in factory
2. factory.Start() starts all registered informers (only v1alpha2)
3. HasSynced calls V1alpha1().APIBindings().Informer() → lazily creates a new v1alpha1 informer, but it is never started
4. An unstarted informer has controller == nil, so HasSynced() returns false indefinitely
5. The DynamicRESTMapper controller never starts — blocked forever in PollUntilContextCancel

Fix

Change the HasSynced check to use V1alpha2().APIBindings(), matching the informer version passed to the controller constructor.

Impact

Without this fix, the DynamicRESTMapper controller never starts, which prevents dynamic API discovery from working correctly for resources introduced via APIBindings.

NONE

[kcp-ci-bot]

Hi @maxpain. Thanks for your PR.

I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[cnvergence]

/ok-to-test

[gman0]

/kind bug

[mjudeikis]

/retest

[mjudeikis]

/lgtm
/approve

[kcp-ci-bot]

LGTM label has been added.

Details

Git tree hash: a0c5264a1572838953b588644dccc21f79b11b11

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mjudeikis

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [mjudeikis]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mjudeikis]

/ok-to-test

[gman0]

/release-note

[kcp-ci-bot]

@gman0: the /release-note and /release-note-action-required commands have been deprecated.
Please edit the release-note block in the PR body text to include the release note. If the release note requires additional action include the string action required in the release note. For example:

```release-note
Some release note with action required.
```

Details

In response to this:

/release-note

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[gman0]

/release-note Fixed informer sync wait

[gman0]

@maxpain please update your release notes in the PR description -- it may be left empty. Like so:

```release-note
NONE
```

[maxpain]

@maxpain please update your release notes in the PR description -- it may be left empty. Like so:

```release-note
NONE

Done

[mjudeikis]

/retest