You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Using a Condition to test if dependencies are met #3643
Is your feature request related to a problem? Please describe.
Currently, we can describe a resource's dependencies using their names in dependsOn and we can also test preconditions with a reconcilePrecondition. However, sometimes a resource may need to depend one "at least one of" some other resource. For example, either an Ingress or a Route depending on the underlying cluster. In this case, dependsOn is not possible and a reconcilePrecondition returning false would delete the resource, which is undesirable for ongoing reconcile cycles.
There could also be cases where, for example, downstream dependents need a generated Route's hostname, but do not depend on the route actually becoming ready for further processing of the workflow, etc. Using a Condition could allow dependencies on sub-resources and not only on a resource's full readiness.
Describe the solution you'd like
An additional option on @Dependent (such as dependenciesMetPrecondition) that would allow programmatic checking on dependencies without removal of an existing secondary resource if it exists. This could be either mutually exclusive with, or in addition to whatever is given in dependsOn. Allowing both would provide a way to test simple dependencies and more complex ones at the same time.
Describe alternatives you've considered
I think more complicated workflows with "virtual" resources (always returning ReconcileResult.noOperation(primary) from reconcile) together with a readyPostcondition could be made to behave similarly, but with the burden of additional code and dependencies in the @Workflow.
Thank you we will take a look on this more in depth. Yes the reconcile pre-condition deletes the resource always is probably not something that always fits. Maybe we could extend the result to describe the intention to delete the resource or just keep it as it is for now. With this we would be a more powerful approach n our hand. What do you think?
Maybe we could extend the result to describe the intention to delete the resource or just keep it as it is for now. With this we would be a more powerful approach n our hand. What do you think?
@csviri that seems reasonable. Something akin to DetailedCondition?
Something that would complement using reconcile pre-conditions in this way would be some kind of "soft" dependency. The purpose would be to ensure the pre-condition is checked only after the dependency has been processed in the reconcile cycle, but it may not necessarily be ready.
Maybe something like String[] reconcileAfter() default {}; on @Dependent?
Activity
csviri commentedon Oct 9, 2026
Hi @MikeEdgar ,
Thank you we will take a look on this more in depth. Yes the reconcile pre-condition deletes the resource always is probably not something that always fits. Maybe we could extend the result to describe the intention to delete the resource or just keep it as it is for now. With this we would be a more powerful approach n our hand. What do you think?
MikeEdgar commentedon Oct 9, 2026
@csviri that seems reasonable. Something akin to
DetailedCondition?MikeEdgar commentedon Oct 12, 2026
Something that would complement using reconcile pre-conditions in this way would be some kind of "soft" dependency. The purpose would be to ensure the pre-condition is checked only after the dependency has been processed in the reconcile cycle, but it may not necessarily be ready.
Maybe something like
String[] reconcileAfter() default {};on@Dependent?