config-db currently caches Kubernetes shared informers by scraper ID, full watch resource list, and auth fingerprint. In a long-running process, if a scraper's watch resources change, the cache key changes and a new dynamic informer factory is created. Any resource that exists in both the old and new watch lists is not stopped by the existing cleanup logic, so the same scraper/cluster can end up with multiple running informers for the same GroupVersionKind. This can also happen when the same watch resources are supplied in a different order, because the watch-list string is order-sensitive.
config-db currently caches Kubernetes shared informers by scraper ID, full watch resource list, and auth fingerprint. In a long-running process, if a scraper's watch resources change, the cache key changes and a new dynamic informer factory is created. Any resource that exists in both the old and new watch lists is not stopped by the existing cleanup logic, so the same scraper/cluster can end up with multiple running informers for the same GroupVersionKind. This can also happen when the same watch resources are supplied in a different order, because the watch-list string is order-sensitive.