Bug: Cache problems with ConfigMaps

[theunrepentantgeek]

Describe the bug

Originally a comment by @nojnhuh on #4926

I think I'm running into this same thing with v2.15.1 (via CAPZ) but for ConfigMaps:

conditions:

• lastTransitionTime: "2025-12-09T18:44:13Z"
  message: /v1, Kind=ConfigMap is not cached
  observedGeneration: 2
  reason: Failed
  severity: Warning
  status: "False"
  type: Ready

CAPZ installs these ASO CRDs itself and passes an empty string to --crd-pattern by default:

resourcegroups.resources.azure.com
natgateways.network.azure.com
managedclusters.containerservice.azure.com
managedclustersagentpools.containerservice.azure.com
bastionhosts.network.azure.com
virtualnetworks.network.azure.com
virtualnetworkssubnets.network.azure.com
privateendpoints.network.azure.com
fleetsmembers.containerservice.azure.com
extensions.kubernetesconfiguration.azure.com

Expected behavior

This shouldn't error.

[theunrepentantgeek]

Update from @matthchr via a different channel ...

I think this is an issue with the same fix but a different "cause" in some ways.

I was thinking secret was the only problem because the only secret we read is the aso-controller one and we don't read any configmaps by default, and resources that read configmaps should declare that in their registration so we'll pull in the configmap watcher in that case, so the only case that was missed for watches was secrets.

I think this is wrong.

We need the watcher even if we write the resource, see ApplyObjAndEnsureOwner -- it calls controllerutil.CreateOrUpdate, which issues a Get and that Get is likely the cause of this error. So what we really ought to do is have resources that can read or write configmaps or secrets declare that they require secrets/configmaps watched. (Though since we have CEL everywhere now I guess that's everything so what you've done here and what we do for secrets is also good/correct).

[theunrepentantgeek]

Keeping open for review in the new year.