From adebc384379eb2e7b2da23c3efdc8af4bf6bfb05 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Attila=20M=C3=A9sz=C3=A1ros?= Date: Tue, 26 May 2026 10:51:21 +0200 Subject: [PATCH 1/2] docs: eventing hides implementation details MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Attila Mészáros --- .../content/en/docs/documentation/eventing.md | 24 ++++++++----------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/docs/content/en/docs/documentation/eventing.md b/docs/content/en/docs/documentation/eventing.md index 7b2cdea854..46a5a66f6a 100644 --- a/docs/content/en/docs/documentation/eventing.md +++ b/docs/content/en/docs/documentation/eventing.md @@ -42,21 +42,17 @@ graph LR classDef controller fill:#326CE5,stroke:#1A4AAF,color:#fff classDef secondary fill:#3AAFA9,stroke:#2B807B,color:#fff ``` - A few things worth highlighting about the diagram above. -- The `ControllerEventSource` is a special, internal event source responsible for handling events -pertaining to changes affecting the primary resource. The SDK registers it automatically for every -controller and you never instantiate it yourself. -- Every controller also gets a dedicated `TimerEventSource` (named -`RetryAndRescheduleTimerEventSource`) that the SDK uses to drive retry attempts after a failed -reconciliation, `UpdateControl.rescheduleAfter(...)` requests, and the periodic max-interval -failsafe trigger. The `EventProcessor` is the sole caller into this timer, scheduling delayed -events back to itself via `scheduleOnce(...)`. Like the controller event source, this one is -wired internally and is not something you register or interact with directly. -- Once an event reaches the `EventProcessor`, dispatch is delegated to the -`ReconciliationDispatcher`, which prepares the execution context, handles finalizers and other -framework concerns, and ultimately invokes `reconcile(...)` on the internal `Controller` wrapper, -which in turn calls the user-implemented `Reconciler`. + +- The framework includes an internal event source (`ControllerEventSource`) for changes affecting the primary resource. The + SDK registers it automatically for every controller, and you never instantiate it yourself. +- Every controller also gets an internal timer-based event source that the SDK uses for delayed + retries, `UpdateControl.rescheduleAfter(...)` requests, and periodic failsafe triggering. Like + the controller event source, it is wired internally and is not something you register or interact + with directly. +- Once an event enters the framework's processing pipeline, the SDK prepares the reconciliation + context, handles finalizers and other framework concerns, and then invokes the user-implemented + `Reconciler`. Events always relate to a given primary resource, and the SDK guarantees that there is no concurrent execution of the reconciler for any given primary resource, even in the presence of From cf86f0a5a34fb6bdbe3c98dea62f17e5c65a4fe7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Attila=20M=C3=A9sz=C3=A1ros?= Date: Tue, 26 May 2026 12:24:13 +0200 Subject: [PATCH 2/2] Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- docs/content/en/docs/documentation/eventing.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/content/en/docs/documentation/eventing.md b/docs/content/en/docs/documentation/eventing.md index 46a5a66f6a..06b8ccf9e9 100644 --- a/docs/content/en/docs/documentation/eventing.md +++ b/docs/content/en/docs/documentation/eventing.md @@ -44,8 +44,9 @@ graph LR ``` A few things worth highlighting about the diagram above. -- The framework includes an internal event source (`ControllerEventSource`) for changes affecting the primary resource. The - SDK registers it automatically for every controller, and you never instantiate it yourself. +- The framework includes an internal event source (`ControllerEventSource`) for changes affecting + the primary resource. The SDK registers it automatically for every controller, and you never + instantiate it yourself. - Every controller also gets an internal timer-based event source that the SDK uses for delayed retries, `UpdateControl.rescheduleAfter(...)` requests, and periodic failsafe triggering. Like the controller event source, it is wired internally and is not something you register or interact