Grandchild module orphans should be destroyed #2786
Conversation
I was worried about the implications of deeply nested orphaned modules in the parent commit, so I added a test. It's failing but not quite like I expected it to. Perhaps I've uncovered an unrelated bug here? /cc @mitchellh
|
Pushed a failing test - see commit message for details. |
| key := m.Path[len(m.Path)-2] | ||
| if _, ok := direct[key]; ok { | ||
| continue | ||
| } |
There was a problem hiding this comment.
I wrote my failing test trying to explore the implications of this. I was worried that this would improperly skip great-grandchildren when the grandchild was orphaned (since the transform, and therefore this function only ever runs on the root path AFAICT).
There was a problem hiding this comment.
Sounds good. I'll take a look. I thought of this but didn't write a test for it, my thought was that since we add the direct module orphan directly, this transform should be called recursively. But I'll take a look.
|
Pushed a fix, it does get called recursively but there was an arithmetic error in there. :) |
|
Bingo, LGTM if the tests pass |
Grandchild module orphans should be destroyed
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Fixes #2770
This was an interesting bug found by @ryanking. Basically: when adding orphan modules to the graph, only direct descendants were added by inspecting the state. If the direct descendant has no state (no resources in the original config), then grandchildren will never get discovered and never added to the graph.
This PR mainly modifies
State.ModuleOrphansto return orphans that have grandchildren even if they're not in the state.This PR also contains a few bug fixes necessary to make this work otherwise, but the above is the meat of the change.
(Aside: we should really switch to a tree structure internally to make functions like ModuleOrphans more efficient than
O(N), but... one day).