improvements

Signed-off-by: Attila Mészáros <a_meszaros@apple.com>

Author: csviri

docs/content/en/blog/news/primary-cache-for-next-recon.md

@@ -2,7 +2,7 @@
 title: How to guarantee allocated values for next reconciliation
 date: 2025-05-22
 author: >-
-  [Attila Mészáros](https://github.com/csviri)
+  [Attila Mészáros](https://github.com/csviri) and [Chris Laprun](https://github.com/metacosm)
 ---
 
 We recently released v5.1 of Java Operator SDK (JOSDK). One of the highlights of this release is related to a topic of
@@ -11,13 +11,13 @@ so-called
 ).
 
 To describe the problem, let's say that our controller needs to create a resource that has a generated identifier, i.e.
-a resource which identifier cannot be directely derived from the custom resource's desired state as specified in its
-`spec` field. In order to record the fact that the resource was successfully created, and to avoid attempting to
+a resource which identifier cannot be directly derived from the custom resource's desired state as specified in its
+`spec` field. To record the fact that the resource was successfully created, and to avoid attempting to
 recreate the resource again in subsequent reconciliations, it is typical for this type of controller to store the
 generated identifier in the custom resource's `status` field.
 
 The Java Operator SDK relies on the informers' cache to retrieve resources. These caches, however, are only guaranteed
-to be eventually consistent. It could happen, then, that, if some other event occurs, that would result in a new
+to be eventually consistent. It could happen that, if some other event occurs, that would result in a new
 reconciliation, **before** the update that's been made to our resource status has the chance to be propagated first to
 the cluster and then back to the informer cache, that the resource in the informer cache does **not** contain the latest
 version as modified by the reconciler. This would result in a new reconciliation where the generated identifier would be
@@ -59,10 +59,8 @@ The trick is to intercept the resource that the reconciler updated and cache tha
 of the informer's cache. Subsequently, if the reconciler needs to read the resource, the SDK will first check if it is
 in the overlay cache and read it from there if present, otherwise read it from the informer's cache. If the informer
 receives an event with a fresh resource, we always remove the resource from the overlay cache, since that is a more
-recent resource. But this **works only** if the reconciler updates the resource using **with optimistic locking**, which
-is handled for you by `PrimaryUpdateAndCacheUtils` provided you pass it a "fresh" (i.e. a version of the resource that
-only contains the fields you care about being updated) copy of the resource since Server-Side Apply will be used
-underneath. If the update fails on conflict, because the resource has already been updated on the cluster before we got
+recent resource. But this **works only** if the reconciler updates the resource using **optimistic locking**. 
+If the update fails on conflict, because the resource has already been updated on the cluster before we got
 the chance to get our update in, we simply wait and poll the informer cache until the new resource version from the
 server appears in the informer's cache,
 and then try to apply our updates to the resource again using the updated version from the server, again with optimistic
@@ -85,13 +83,10 @@ The following diagram sums up the process:
 
 ```mermaid
 flowchart TD
-    A["Update Resource with Lock"] --> B{"Successful?"}
-    B -- Fails on conflict --> D{"Resource updated from cluster?"}
-    D -- " No: poll until updated " --> D
-    D -- Yes --> n4["Apply desired changes on the resource again"]
+    A["Update Resource with Lock"] --> B{"Is Successful"}
+    B -- Fails on conflict --> D["Poll the Informer cache until resource updated"]
+    D --> A
     B -- Yes --> n2{"Original resource still in informer cache?"}
     n2 -- Yes --> C["Cache the resource in overlay cache"]
     n2 -- No --> n3["Informer cache already contains up-to-date version, do not use overlay cache"]
-    n4 --> A
-
 ```