From 85843e6e025983ac18f083428dd8c4d475cc8e1c Mon Sep 17 00:00:00 2001 From: matte21 Date: Mon, 28 Oct 2019 14:12:22 +0100 Subject: [PATCH] Clarify that OnUpdate can mask delete and recreate Kubernetes-commit: ff543ddfc09adf3d0abdf42f9d9fbd57c3ab4b43 --- tools/cache/shared_informer.go | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/tools/cache/shared_informer.go b/tools/cache/shared_informer.go index f59a0852..5c2dcea0 100644 --- a/tools/cache/shared_informer.go +++ b/tools/cache/shared_informer.go @@ -106,7 +106,18 @@ import ( // and index updates happen before such a prescribed notification. // For a given SharedInformer and client, the notifications are // delivered sequentially. For a given SharedInformer, client, and -// object ID, the notifications are delivered in order. +// object ID, the notifications are delivered in order. Because +// `ObjectMeta.UID` has no role in identifying objects, if an object +// O1 with ID (e.g. namespace and name) X and `ObjectMeta.UID` U1 in +// the SharedInformer's local cache is deleted and shortly after +// another relevant object O2 with ID X and `ObjectMeta.UID` U2 is +// created a client has no guarantee of seeing O1's deletion and +// O2's creation as two separate notifications, it might as well +// receive a single update notification where the old object is O1 +// and the new object is O2. Clients that need to detect such cases +// might do so by comparing the `ObjectMeta.UID` field of the old +// and the new object in the code that handles update notifications +// (i.e. `OnUpdate` method of ResourceEventHandler). // // A client must process each notification promptly; a SharedInformer // is not engineered to deal well with a large backlog of