wip

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

Author: csviri

docs/content/en/blog/news/read-after-write-consistency.md

@@ -1,7 +1,6 @@
 ---
 title: Welcome read-cache-after-write consistency!
-# todo issue with this?
-#date: 2026-03-25
+date: 2026-03-13
 author: >-
   [Attila Mészáros](https://github.com/csviri)
 ---
@@ -42,6 +41,8 @@ much simpler to reason about!**
 
 This post will deep dive in this topic, explore the details and rationale behind it.
 
+See the related umbrella [issue](https://github.com/operator-framework/java-operator-sdk/issues/2944) on GitHub.
+
 ## Informers and eventual consistency
 
 First we have to understand a fundamental building block of Kubernetes operators: Informers.
@@ -229,24 +230,54 @@ events that we received meanwhile, and make a decision to propagate any further
 
 However, this way we significantly reduce the number of reconciliations, thus making the whole process much more efficient.  
 
+### The case for instant reschedule
+
+We realize that some of our users might rely on the fact that the reconciliation is triggered by own updates.
+To support backwards compatibility or rather migration path, we provide now a way to instruct the framework 
+to queue an instant reconciliation:
+
+```java
+public UpdateControl<WebPage> reconcile(WebPage webPage, Context<WebPage> context) {
+ 
+    // omitted reconciliation logic
+    
+   return UpdateControl.<WebPage>noUpdate().reschedule();
+}
+```
+
 ## Additional considerations and alternatives
 
 An alternative approach would be that when we do an update we don't trigger the next reconciliation until the 
 target resource is not in the Informers cache. The pro side of this is that we don't have to maintain an 
 additional cache of the resource, just the target resource version; therefore there this appraoch might have
-a smaller memory footprint, but not necessarily. 
+a smaller memory footprint, but not necessarily. This the related [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/5647-stale-controller-handling#proposal)
+that takes this approach. 
 
 On the other hand, when we do a request the response object is always deserialized, regardless if we are going
 to cache it or not. This object in most cases will be cached for a very short time; and later garbage collected.
+Therefore, the memory overhead should be minimal.
 
+Having the TRC has an additional advantage, since we have the resource instantly in our cashes, we can in 
+the same reconciliation elegantly continue on reconciliation and reconcile resources that are depending
+on the latest state. More concretely helps also for our [Dependent resources / Workflow](../../docs/documentation/dependent-resource-and-workflows/workflows.md#reconcile-sample) 
+which rely on up-to-date caches. In this sense, this is much more optimal regarding throughput.
 
+## Conclusion
 
+I personally worked on a prototype of an Operator which was depending on an unreleased version of JOSDK already 
+implementing these features. The most obvious gain was how much simpler the reasoning is in some cases and how it reduces the corner
+cases that we would have to solve otherwise with [expectation pattern](https://ahmet.im/blog/controller-pitfalls/#expectations-pattern)
+or other facilities. 
 
-## Conclusion
+## Special thanks
+
+I would like to thank all the contributors that directly or indirectly contributed like [metacosm](https://github.com/metacosm),
+[manusa](https://github.com/manusa) and [xstefank](https://github.com/xstefank).
 
-## Notes
+Last but certainly not least, specially thanks to [Steven Hawkins](https://github.com/shawkins) 
+with who maintains the Informer implementation in [fabric8 Kubernetes client](https://github.com/fabric8io/kubernetes-client),
+implemented the first version of the algorithms, then we together iterated multiple times on it.
+Covering all the edge cases was quite an effort.
+Just to as a highlight I put here the [last one](https://github.com/operator-framework/java-operator-sdk/issues/3208).
 
-TODO:
-- alternatives => deferring reconciliation, this is optimized for throughput
-- filter events
-- reschedule
+Thank you!

docs/content/en/blog/releases/v5-3-release.md

@@ -54,7 +54,8 @@ If your reconciler relied on being re-triggered by its own writes, a new `resche
 > in-flight updates. Use `context.getSecondaryResources(..)` or `InformerEventSource.get(ResourceID)`
 > instead.
 
-See the [reconciler docs](/docs/documentation/reconciler#read-cache-after-write-consistency-and-event-filtering) for details.
+See the related [blog post](../news/read-after-write-consistency.md) 
+and [reconciler docs](/docs/documentation/reconciler#read-cache-after-write-consistency-and-event-filtering) for details.
 
 ### MicrometerMetricsV2
 

operator-framework/src/test/java/io/javaoperatorsdk/operator/baseapi/patchresourcewithssa/PatchResourceWithSSAReconciler.java

@@ -42,7 +42,7 @@ public UpdateControl<PatchResourceWithSSACustomResource> reconcile(
       res.setSpec(new PatchResourceWithSSASpec());
       res.getSpec().setControllerManagedValue(ADDED_VALUE);
       // test assumes we will run this in the next reconciliation
-      return UpdateControl.patchResource(res).reschedule();
+      return UpdateControl.<PatchResourceWithSSACustomResource>noUpdate().reschedule();
     } else {
       res.setStatus(new PatchResourceWithSSAStatus());
       res.getStatus().setSuccessfullyReconciled(true);