Informer-cache lag lets a status patch overwrite a condition set 49ms earlier

The helper is short enough to read whole. Per the post, it runs four operations inside `retry.RetryOnConflict(retry.DefaultRetry, ...)`:

1. Deep-copy the object and `Get` it through `UncachedClient` into the copy ^[4]. 2. Deep-copy that fresh object as `base` ^[4]. 3. Call the step's `mutate` on the fresh object. It may return `ErrNoOp`, and the caller short-circuits ^[4][5]. 4. Patch status with `client.MergeFrom(base)` ^[4].

Because the read sits inside the closure, a conflict retry fetches the object again instead of reusing the first snapshot ^[4].

The 49ms figure is one fleet's observation: custom controllers on managed GKE at a European automaker ^[14]. For it to transfer, a second write has to land inside the cache's lag window after the first. Between reconciles the gap is small beside the interval. The post's example controller reconciles every 20 seconds ^[9], roughly 400 times the 49ms window ^[13]. The exposure is inside a reconcile, where the post says the cache can lag by tens of milliseconds ^[8].

In our view, one extra GET per status write is the right trade where several conditions are written per reconcile. The context is a controller that chains steps, as this one does. A controller that writes status once per reconcile has less to gain.

Skipping a behind-cache reconcile and reading fresh are different remedies. The post text breaks off mid-sentence in the bug section, so it does not say how a controller detects the lag on v1.36 or whether the authors dropped the uncached read there ^[15]. We would keep the uncached read until that is documented.