shawkins
commented
1 year ago Also this is not fully defensive - presumably because of missing events / invalid cache state the control plane was not receiving status updates either.
If we end up seeing more frequent sync restarts due to these changes we'll have to find a root cause - and/or go back to using things like a timed restart job to ensure that the watches are fresh.
sonarcloud[bot]
This is purely trying to be more defensive to what was seen in MGDSTRM-10277. However there remains a completely unknown root cause - I didn't see anything exceptional called out. It's also not clear why only sync would be affected - we've moved up enough in the operator sdk such that it's using an informer for the primary controller resource (managedkafka) that should be exactly the same as what the sync is running.