Attila Mészáros

Usually events are also persisted ideally. But are used usually to propagate information about the cluster state. Typically if a pod cannot start for some reason, there will be no...

> @csviri do you have any link regarding the usage of events solely for "cluster state" events? Super interested in understanding this more! I thing there is no single best...

So I agree that this is useful to support. Problem is if we are not able to deserialize, we don't even know the resource ID (name + namespaces). But pretty...

yes, that is one way to approach it.

I think what @andreaTP means that, when an error occurs during de-serialization of a resource, we could try to de-serialize it to `GenericKubernetesResource`. And the error handler could work with...

> This is expected to be tackled as part of: #1422 It's not IMO, this is a separate issue. The if an informer is not able to de-serialize a resource...

While I agree that we try to implement this with a callback, for the other we have now a agreed design for the first iteration: https://github.com/java-operator-sdk/java-operator-sdk/issues/1422#issuecomment-1227355076

> Sure but aren't they used to check backwards compatibility? Probably not, at least that is also covered by the normal samples. Basically the default samples cover that.

the tests are failing quite randomly, (also there are some solid fails too :) ) will investigate later probably.

Hi @shawkins , it's an interesting idea, the cache is quite an internal thing, currently we are actually changing the implementation regarding to it. So it will be more extensible...