Resolve dependencies transitively across the full dependency graph - #20
Merged
Conversation
veil's dependency resolution was one-hop: a resource's dependent hooks only fired for its own directly-declared `dependencies`, never for the dependencies of a target it depends on. A service depending on package/api-rate-limits, which itself depends on dynamo-table/rate-limit-exceeded, never triggered the dynamo-table's dependent hooks. applyDependency (single edge) is replaced with applyDependencies, a breadth-first, cycle-safe, visit-once walk over the full transitive dependency graph reachable from the render root — the same shape graph.go's BFS already uses for `veil graph`. applyDependentHooks applies each edge's qualifying dependent hooks against the one shared bundle threaded through the whole walk. At every edge, ctx.consumer is the immediate parent in the chain, not necessarily the render root. This is a global capability change: every kind's dependencies resolve this way now, not something scoped to any one kind. PLAT-8321
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
render.goresolved dependencies strictly one-hop:applyDependencynever recursed into a target's ownDependencies. A service depending onpackage/api-rate-limits, which itself depends ondynamo-table/rate-limit-exceeded, never triggered the dynamo-table's dependent hooks — the dependency never reached the service.Resolution
veil's core now walks the full reachable dependency graph — breadth-first, cycle-safe, visit-once, the same shape
graph.go's BFS already uses forveil graph— and applies qualifying dependent hooks along that walk, not just visualizes it.applyDependency(single edge) →applyDependencies(BFS walk) +applyDependentHooks(per-edge application).ctx.consumerat each hop is the immediate parent in the chain, not necessarily the render root — matches the existing per-(target-kind, consumer-kind) dependent-hook contract, just applied at every hop instead of only the first.SPEC.mdupdated (pipeline order, render-time execution, numbered pipeline steps) to describe the transitive walk.Tests
New
pkg/render/render_dependencies_test.go:TestMultiHopDependencyAppliesTransitiveDependentHooks— reproduces the service → package → dynamo-table scenario exactly.TestDependencyCycleAppliesEachEdgeOnceWithoutInfiniteLoop— mutual cycle terminates, each direction's hook fires once.TestDiamondDependencyFiresTargetHookOncePerIncomingEdge— a target reached via two independent parents fires its dependent hook once per edge, not deduped by node.Closes PLAT-8321.