Could this even be an error?

hmm, maybe even throw an exception at this point?

Yes, the only problematic behavior could be poorly written mock servers that are providing invalid resourceVersions.

This handling doesn't seem directly related to resourceVersion comparability. It's to handle the case where the event comes in before the create / update puts the result in the cache.

Do you want to not worry about this case now, or is there some other locking or other logic not in this pr handling this case?

yes, this alone is not enough, but we might simplify it anyways, and just react on event that our last updated resource event.

Can you explain this a bit more? I'm not sure at the point in time if we have enough information to know if the incoming event is from our reconciliation, or another actor.

This is an outdated version but the current one:
this implementation assumes that we want to trigger reconiliation only on newer version of resources, that came after our update. So basically we store the latest updated version even if we don't cache the resource in the temporal cache in case resource versions are equal. So new resources can be compared with this one. Essentially dropping events for our update and the updates happened before.

To clarify here's the timing sequence that the code is guarding against:

• The reconciliation starts to do an update of a resource at v1.
• Before the kubernetes client receives that result, the informer receives the event for the transition from v1 -> v2
• That event is later than the lastest known event to the TemporaryResourceCache because it has yet to transition to v2, so canSkipEvent will return false.

ahh, yes, thank you pointing this out, might separate the PR and see if It is possible to handle that without the annotation.

As far as I remember the only two approaches are locking or the annotation. Locking is more intrusive in other parts of the code, whereas the current annotation approach is prone to reconciliation loops if SSA change detection isn't perfect. We could probably come up with a way to reason over a stable hash, but that starts seeming expensive for this problem.

This strategy can also be used instead of tombstones. If we attempt to put something that already has been deleted, the delete event (and the latest in general) is guarenteed to have been based upon a resourceVersion that is newer.

if you have the time pls add a pr for that.

if you have the time pls add a pr for that.

Since that would be based upon the latest tracking, could you introduce / merge that (which will effectively shadow the latest tracked by the informer, but I'm not sure if you have anyone trying to use that directly) without the changes to the previous annotation? Or do you think you can complete that work in the near term?

Actually I think this can just be something like#2989