Skip to content

fix: use the cached desired state when selecting an external secondary resource - #3528

Draft
csviri wants to merge 1 commit into
operator-framework:mainfrom
csviri:fix/external-dependent-desired-state-cache
Draft

fix: use the cached desired state when selecting an external secondary resource#3528
csviri wants to merge 1 commit into
operator-framework:mainfrom
csviri:fix/external-dependent-desired-state-cache

Conversation

@csviri

@csviri csviri commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

AbstractExternalDependentResource.selectTargetSecondaryResource called
desired(primary, context) directly instead of going through
getOrComputeDesired(context).

getOrComputeDesired exists precisely so that desired is invoked at
most once per reconciliation; its javadoc states that the SDK should call
it exclusively and that desired should never be called directly, because
this "supports scenarios where idempotent computation of the desired state
is not feasible".

Calling desired directly here means it is computed an extra time on
every reconciliation of an external dependent resource: once to pick the
target secondary and again from match/reconcile via the cache. That is
wasted work in all cases, and produces an inconsistent desired state for
any implementation whose desired is not idempotent - exactly the case
the cache is there to support.

KubernetesDependentResource already routes through getOrComputeDesired
via targetSecondaryResourceID; this brings the external variant in line.

No unit test is added: the code path is only covered by the external
dependent integration tests under operator-framework, which need a
cluster.

Part of #3517

…y resource

`AbstractExternalDependentResource.selectTargetSecondaryResource` called
`desired(primary, context)` directly instead of going through
`getOrComputeDesired(context)`.

`getOrComputeDesired` exists precisely so that `desired` is invoked at
most once per reconciliation; its javadoc states that the SDK should call
it exclusively and that `desired` should never be called directly, because
this "supports scenarios where idempotent computation of the desired state
is not feasible".

Calling `desired` directly here means it is computed an extra time on
every reconciliation of an external dependent resource: once to pick the
target secondary and again from `match`/`reconcile` via the cache. That is
wasted work in all cases, and produces an inconsistent desired state for
any implementation whose `desired` is not idempotent - exactly the case
the cache is there to support.

`KubernetesDependentResource` already routes through `getOrComputeDesired`
via `targetSecondaryResourceID`; this brings the external variant in line.

No unit test is added: the code path is only covered by the external
dependent integration tests under `operator-framework`, which need a
cluster.
Copilot AI review requested due to automatic review settings July 30, 2026 09:05
@openshift-ci openshift-ci Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 30, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a correctness/performance issue in the external dependent resource flow by ensuring the desired state used to select the target secondary resource comes from the per-reconciliation desired-state cache, rather than recomputing it.

Changes:

  • Update AbstractExternalDependentResource.selectTargetSecondaryResource to use getOrComputeDesired(context) instead of calling desired(primary, context) directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants