@metacosm @shawkins @xstefank
This should be the new implementation that is now aware of intermediate events. So only filters out events for controller own changes. The algorithm is I think even simpler than before. The idea is simple, we record the events during the update, and we check at the end if there was event that is not related to our changes; if no we don't propagate an event.
If yes, we propagate an Update events, that contains as resource from the first event as previous version, latest as the actual resource + some edge case with delete event. ( This is important because filters might relay on the changed resource).

This approach however would be bulletproof if we handle the re-list in the informer from the fabric8 pr above. Since in some (rather extreme) edge cases, if there is a re-list, event might be lost. So the idea would be (will create a separate PR) that, if we got notified that goind to be a re-list we flip a switch, and until the sync is finished we simply allow to pass (don't filter) any events. I think without that this is not even possible to do 100% correctly. (but maybe @shawkins has some ideas)

https://github.com/fabric8io/kubernetes-client/pull/7899/changes

So this is the correct way of doing, with "maximal precision", the good think is that it is actually relatively simple.
However something so be aware about.

1. We record the events related to that one resource. This in average case (like when there is an event from our modification or one from 3rd party) is 0-2 events, in some extreme edge cases might be much more, when there are very frequent update on the resource both from the controller and some 3rd party, this might be more - even that this is for a limited time - while our updates are finished.

2. Regarding time, we currently support multiple concurrent updates, and we finish the processing after all concurrent updates are finished. Theoretically if we have a many-to-one scenario to many primary resources reconciliations write one single resource, this could be long even could lead to "starvation" like situation so the update is not finished. First of all, in controller many-to-one is quite rate, we could already tell don't use this feature for such scenarion. But also I will iterate on this a bit and maybe have it time bound / or request number bound as failsafe, that will solve this issue.

added #3406 that covers the informer re-list, will continue now adding unit tests etc.

@shawkins was thinking about this more, and having optimistic locking would be a too strong restriction in my opinion, compared to that even not doing event filtering is a better option.

So I prepared this PR and the one that we can merge subsequently:
#3406

With these two we would cover this functionality by just filtering events directly related to our updates, or not do filtering when there is a relist going on.
The algorithms are comparable to the current one in terms of complexity, not significantly more complex.

If the complexity would be proven to an issue and we would still hit some problematic cases, as an alternative we could just do a heuristic that would be very simple:

• cache the latest resource (that we do regardless of event filtering, no issues with that at all)
• and filter only event where the new resource has the resource version of the cached resource.
• maybe with some minimal information that we received already other event.

But for both alternatives, we at the end need to be aware that re-list happened and events might be lost, so regardless we would need this:
fabric8io/kubernetes-client#7899

please let me know what do you think. Will finalize the PRs today.

cc @manusa

Just one thought about the complexity, yes these algorithms are not trivial, but also would make it much easier for the users to implement reconciliation logic. So there is such complexity in the framework or at the end in some cases in the reconcilers, so having these problems solved by is where the frameworks are really useful.

replaced by: #3414