Skip to content

Guard against Kustomization tree cycles - #6000

Open
AkashKumar7902 wants to merge 1 commit into
fluxcd:mainfrom
AkashKumar7902:agent/guard-tree-cycles
Open

Guard against Kustomization tree cycles#6000
AkashKumar7902 wants to merge 1 commit into
fluxcd:mainfrom
AkashKumar7902:agent/guard-tree-cycles

Conversation

@AkashKumar7902

Copy link
Copy Markdown

Closes #5998

What

Guard flux tree kustomization recursion with the current traversal
path. Cyclic inventory paths now stop at an ancestor instead of querying
the API server until the command times out.

Path-local tracking keeps shared non-cyclic subtrees traversable under
independent branches.

Tests

  • make tidy fmt vet && make test

Local testing

  • Built flux from e8594afcd6c29c9a573464892d0c645c1e2cdf65.
  • Against a disposable Kubernetes 1.36.2 envtest API server, seeded a
    two-object Kustomization inventory cycle. The base binary exited 1 at
    the two-second timeout; the candidate exited 0 and printed cycle-a
    followed by cycle-b once each.

Assisted-by: codex/gpt-5

Track Kustomizations in the active traversal path so cyclic
inventories stop before issuing repeated API requests.

Add a golden regression test for a two-object inventory cycle.

Assisted-by: codex/gpt-5
Signed-off-by: Akash Kumar <meakash7902@gmail.com>
@AkashKumar7902
AkashKumar7902 marked this pull request as ready for review July 19, 2026 16:03
@gecube

gecube commented Aug 1, 2026

Copy link
Copy Markdown

Hi @AkashKumar7902,
Thanks for taking the time to work on this and for trying to address the issue I reported!
One question came to mind though: how does this approach behave with more complex dependency graphs?
For example, not just a simple A <-> B cycle, but something like:

A -> B -> C -> D -> ... -> Z -> A

or even graphs where multiple cycles are interconnected, for example:

        +---- C ----+
        |           |
A -> B -+-> D -> E -+-> F
^        \         /
|         \-> G <-/
+------------- H --+

or:

A -> B -> C -> D
^         |    |
|         v    |
F <- E <- G <- H

or a graph with nested/overlapping cycles:

A -> B -> C -> D -> E
     ^    |         |
     |    v         v
     H <- G <- F <- I
          ^         |
          +---------+

Those are usually much harder to detect correctly than the trivial two-node case.
More generally, dependency graph analysis is a surprisingly difficult problem. Garbage collection and cycle detection are areas where, as far as I know, the industry still has to balance correctness against performance. Simple loop-detection approaches often miss more complicated topologies, while more advanced graph algorithms can become quite expensive in terms of CPU and memory on large dependency graphs.
It would be interesting to understand where this implementation sits on that spectrum and whether there are any known limitations regarding longer or overlapping cycles.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

flux tree: unbounded recursion when Kustomization inventories reference each other

2 participants