Hierarchical ancestry changes in one branch affecting other branches and causing duplicate parents

[minitriga]

Description

A bug has been reported where changing hierarchical ancestry in one branch appears to affect other branches, and in some cases results in nodes showing multiple parents simultaneously.

Environment

• Version: v1.7.4
• Affected Feature: Hierarchical nodes with parent/child relationships

Symptoms

1. Cross-branch ancestry contamination: When changing the parent of a hierarchical node in one branch, the change may leak into other branches
2. Duplicate parents: After changing ancestry and reverting it back, nodes can end up with two parents at the same time
3. UI vs Data discrepancy: The UI may show the correct single parent, but querying the data returns multiple parents
4. Persistent corruption: The only known workaround is to delete the affected node and recreate it

Reproduction Attempt

Wim tested with a simplified schema on v1.7.4 and could not reproduce the issue:

---
version: "1.0"
generics:
  - name: Generic
    namespace: Location
    hierarchical: true
    attributes:
      - name: name
        kind: Text
        optional: false
nodes:
  - name: Region
    namespace: Location
    inherit_from:
      - LocationGeneric
    display_label: "{{ name__value }}"
    parent: ""
    children: LocationCountry
  - name: Country
    namespace: Location
    inherit_from:
      - LocationGeneric
    display_label: "{{ name__value }}"
    parent: LocationRegion 
    children: ""

Test steps that worked correctly:

1. In main branch: Created regions "Europe" and "Americas"
2. In main branch: Created country "Belgium" with parent set to "Europe"
3. Created a new branch
4. In new branch: Changed parent of "Belgium" to "Americas"
5. Switched back to main branch
6. Expected: Belgium's parent should still be "Europe" in main
7. Actual: Belgium's parent was correctly still "Europe" in main ✓

However, the original reporter is experiencing issues with a more complex hierarchy:
rack -> room -> site -> metro -> country -> region -> global

Additional Context

• No branch-agnostic nodes are used in the affected setup
• Hierarchical tree UI issue: Wim noted that the hierarchical tree does not properly update when changing hierarchy, which may be a separate but related issue
• Possible relation to old bug: Reporter suspects this might be a remnant of an old ancestry issue that was fixed in earlier releases
• Data level issue confirmed: This is not just a UI bug - querying the data shows multiple parents

Workaround

Delete the affected node and recreate it with the correct parent relationship.

Next Steps

• Obtain a backup from the affected environment for investigation
• Test with the complex hierarchy schema (7 levels: rack -> room -> site -> metro -> country -> region -> global)
• Test the specific sequence: change ancestry -> revert ancestry -> observe duplicate parents
• Investigate Neo4j relationships for affected nodes
• Check if this is related to previous ancestry bugs that were fixed

Reporter

Discord user: overloadbit
Thread date: 2026-02-07

[polmichel]

Root cause analysis

Branch: ai-bug-pipeline-8395-hierarchy-dup-parents
Bug clarity: CLEAR
Code identification: RESOLVED

Root cause: NodeGetHierarchyQuery does not filter out status="deleted" IS_RELATED edges when querying on the default branch, causing deleted hierarchical relationships (created during merge) to still be traversable, returning multiple parents for a single node.

Affected files:

• backend/infrahub/core/query/node.py -- lines 2367-2385: The default branch case (else block at line 2379) passes peers through without any status="active" validation, while the non-default branch case correctly checks is_active. After a branch merge that deletes a hierarchical relationship, status="deleted" IS_RELATED edges are created on the default branch with to IS NULL, which pass the temporal branch filter and allow the query to traverse through deleted relationships to reach old parents.

Explanation:

The bug manifests through this sequence:

1. A hierarchical node (e.g., Belgium) has parent=Europe on the default branch (via Relationship vertex R1 with active IS_RELATED edges).
2. On a user branch, Belgium's parent is changed to Americas. This creates status="deleted" IS_RELATED edges for R1 on the user branch, and new active IS_RELATED edges for a new Relationship vertex R2 (Belgium-Americas).
3. The branch is merged to the default branch. The DiffMergeQuery (lines 313-378 in backend/infrahub/core/diff/query/merge.py):
   • Closes R1's active IS_RELATED edges on the default branch by setting to
   • Creates new status="deleted" IS_RELATED edges for R1 on the default branch (with to IS NULL)
   • Creates new status="active" IS_RELATED edges for R2 on the default branch
4. After merge, NodeGetHierarchyQuery on the default branch:
   • The path [:IS_RELATED*2..N { hierarchy: $hierarchy }] traverses through R1's deleted edges (they pass the branch filter because to IS NULL)
   • It also traverses through R2's active edges
   • Both Europe (via R1) and Americas (via R2) are returned as parents
   • The DISTINCT dedup doesn't help because they're different nodes

The non-default branch case (lines 2368-2378) correctly handles this by computing is_active = all(r IN relationships(path) WHERE (r.status = "active")) and filtering with WHERE is_active = TRUE. The default branch case (lines 2379-2382) skips this entirely, just doing WITH peer with no status check.

The standard RelationshipGetPeerQuery (used by node detail views) is NOT affected because it always checks is_active = TRUE (line 892 of relationship.py). This explains the reported UI vs data discrepancy: the UI node detail shows the correct single parent, but hierarchy tree queries and query_hierarchy/count_hierarchy in NodeManager return duplicates.

Fix strategy

Approach: Add status="active" filtering to the default branch case of NodeGetHierarchyQuery.query_init(). The initial MATCH query (line 2356-2365) should conditionally include AND all(r IN relationships(path) WHERE r.status = "active") when on the default branch. Alternatively, add a verification CALL subquery in the default branch else block (lines 2379-2382) that re-matches the path with an active status check, similar to the non-default branch case but without the branch_level priority logic (unnecessary on default branch where all edges are branch_level=1).

The recommended approach is to add the status filter to the initial MATCH for the default branch, since it's simpler and doesn't require re-matching:

In the initial query template (line 2356-2365), add a conditional active status filter:

• When self.branch.is_default: add AND all(r IN relationships(path) WHERE r.status = "active") to the WHERE clause
• When not default: leave unchanged (the CALL block handles it)

Scope: Single file change in backend/infrahub/core/query/node.py, NodeGetHierarchyQuery.query_init() method, approximately 3-5 lines changed. The fix should also update line 2385 to keep the where_clause logic consistent (though it becomes less critical if the initial MATCH already filters).

Do NOT:

• Modify DiffMergeQuery to stop creating status="deleted" edges during merge -- the merge behavior is correct per the database schema design, the query consumer should handle deleted edges properly
• Add status filtering to the non-default branch initial MATCH -- this would break the priority resolution logic that needs to see all edges (including deleted ones on different branches) to determine the winner
• Modify RelationshipGetPeerQuery -- it already handles this correctly

Notes for downstream agents

• The test should create a hierarchical schema (generic with hierarchical: true and at least two node types), create a parent-child relationship on main, change the parent on a branch, merge the branch, then verify that querying the hierarchy on main returns only the new parent (not both old and new).
• The test must go through the full merge flow to trigger the DiffMergeQuery that creates status="deleted" edges on the default branch. Simply changing parents on a branch without merging won't reproduce the bug.
• A more complex hierarchy (3+ levels) should also be tested to ensure the path traversal with [:IS_RELATED*2..N] works correctly through multiple levels after merge.
• The NodeGetHierarchyQuery is used by: NodeManager.query_hierarchy(), NodeManager.count_hierarchy(), ManyRelationshipResolver.get_descendant_ids(), and DiffHierarchyEnricher. All of these are affected.
• Edge case: after merge, if you revert the parent back on another branch and merge again, the default branch would accumulate more status="deleted" edges. The fix must handle multiple deleted edges for the same relationship vertex.

[polmichel]

Draft PR with a failing replication test: #8836

The test (TestDiffAndMerge::test_hierarchy_parent_change_on_branch_after_merge) creates a hierarchical location setup on main, changes a node's parent on a branch, merges the branch, then verifies the hierarchy query returns only the new parent. It currently fails because NodeGetHierarchyQuery returns both old and new parents on the default branch.

[polmichel]

Fix implemented and pushed to PR #8836. The fix adds status="active" filtering to NodeGetHierarchyQuery on the default branch, preventing traversal of deleted IS_RELATED edges after merge. The replication test passes.