Expected watch type do not match received event object type

[weilaaa]

What happened?

Keep outputting warning log:

E0629 03:21:41.999303       1 reflector.go:477] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:229: expected type *v1.ConfigMap, but watch event object had type *unstructured.Unstructured
E0629 03:21:42.036111       1 reflector.go:477] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:229: expected type *v1.ConfigMap, but watch event object had type *unstructured.Unstructured
E0629 03:21:42.711482       1 reflector.go:477] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:229: expected type *v1.ConfigMap, but watch event object had type *unstructured.Unstructured
E0629 03:21:42.714799       1 reflector.go:477] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:229: expected type *v1.ConfigMap, but watch event object had type *unstructured.Unstructured
E0629 03:21:42.962754       1 reflector.go:477] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:229: expected type *v1.ConfigMap, but watch event object had type *unstructured.Unstructured
E0629 03:21:43.023051       1 reflector.go:477] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:229: expected type *v1.ConfigMap, but watch event object had type *unstructured.Unstructured

What expected?

expected no warning log.

Version

sigs.k8s.io/controller-runtime v0.8.3 k8s.io/client-go v0.20.6

[FillZpp]

That's weird, it seems to be caused by creating a ShareInformer with *v1.ConfigMap object but the ListWatch is for *unstructured.Unstructured.

[weilaaa]

Yeah, I think so. But I can't find any scenes cause to that. In Controller-Runtime, ConfigMap should be placed in structured InformersMap, that should not happened.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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/test-infra repository.