bug: Test for infrahub-bug-pipeline app

[polmichel]

Component

API Server / GraphQL

Infrahub version

1.8.4

Current Behavior

I created a schema and leveraged relationship direction and generics to capture my use case. However in some certain situations it's possible for data to slips in and break the relationship cardinality.

In the logs I can see:

Traceback (most recent call last):
  File "/.venv/lib/python3.13/site-packages/graphql/execution/execute.py", line 530, in await_result
    return_type, field_nodes, info, path, await result
                                          ^^^^^^^^^^^^
  File "/.venv/lib/python3.13/site-packages/opentelemetry/util/_decorator.py", line 71, in async_wrapper
    return await func(*args, **kwargs)  # type: ignore
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/source/backend/infrahub/database/__init__.py", line 519, in wrapper
    return await func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/source/backend/infrahub/graphql/resolvers/resolver.py", line 242, in default_paginated_list_resolver
    objs = await NodeManager.query(
           ^^^^^^^^^^^^^^^^^^^^^^^^
    ...<11 lines>...
    )
    ^
  File "/source/backend/infrahub/core/manager.py", line 190, in query
    response = await cls.get_many(
               ^^^^^^^^^^^^^^^^^^^
    ...<8 lines>...
    )
    ^
  File "/source/backend/infrahub/core/manager.py", line 1188, in get_many
    await cls._enrich_node_dicts_with_relationships(
    ...<8 lines>...
    )
  File "/source/backend/infrahub/core/manager.py", line 1266, in _enrich_node_dicts_with_relationships
    await cls._enrich_one_node_with_relationships(
    ...<6 lines>...
    )
  File "/source/backend/infrahub/core/manager.py", line 1316, in _enrich_one_node_with_relationships
    raise ValueError("At most, one relationship expected")
ValueError: At most, one relationship expected

Expected Behavior

I expect that the backend throw me off while trying to add a second edge to a relationship with cardinality one.

Steps to Reproduce

• Spin infrahub
• Load this schema

---
# yaml-language-server: $schema=https://schema.infrahub.app/infrahub/schema/latest.json
version: "1.0"

nodes:
  - name: UnicastIPAddress
    namespace: Network
    inherit_from:
      - BuiltinIPAddress
    relationships:
      - name: layer3
        peer: InterfaceLayer3
        kind: Generic
        optional: true
        cardinality: one
        identifier: ip__l3interface
        direction: inbound

  - name: AnycastIPAddress
    namespace: Network
    inherit_from:
      - BuiltinIPAddress
    relationships:
      - name: layer3
        peer: InterfaceLayer3
        kind: Generic
        optional: true
        cardinality: many
        identifier: ip__l3interface
        direction: inbound

  - name: Layer3
    namespace: Interface
    attributes:
      - name: name
        kind: Text
        unique: true
    relationships:
      - name: ip_addresses
        peer: BuiltinIPAddress
        kind: Attribute
        optional: true
        cardinality: many
        identifier: ip__l3interface
        direction: outbound

• Using the UI create one UnicastIPAddress record
• Then create a first Layer3 record that point toward the previously created IP
• Repeat that operation

=> This effectively added two interfaces to the UnicastIPAddress record even tho only one should be allowed. Going back to the IPAM module the interface should crash with the above message.

Additional Information

I can't say it for sure but I haven't managed to reproduce the issue without using the BuiltinIPAddress generic. It doesn't seem to produce the same issue using a different generic...

[polmichel]

/bug-analyze

[github-actions]

✅ Bug analyst agent completed successfully!

Analysis complete. Root cause identified and posted as a comment on issue #9. No further action required in this turn.

[infrahub-bug-pipeline]

Root cause analysis for #9

Issue: bug: Test for infrahub-bug-pipeline app
Based on: da919b3dfd9960c71096cfaa4fa49526979aaf36
Bug clarity: CLEAR
Code identification: RESOLVED

Root cause

RelationshipCountConstraint.check() bypasses all cardinality validation when the relationship's peer is a generic type (e.g., BuiltinIPAddress) because it only searches for the reverse relationship on the generic schema itself, never on the concrete child types where the cardinality: one constraint is actually defined.

Affected files

• backend/infrahub/core/relationship/constraints/count.py — lines 43–46: early return when peer_rels is empty causes the constraint to be silently skipped for all generic peers
• backend/infrahub/core/node/lock_utils.py — lines 90–95: same generic-peer blind spot means the concurrency lock for the peer's cardinality-one relationship is also never acquired

Explanation

The bug occurs in RelationshipCountConstraint.check():

peer_schema = registry.schema.get(name=relm.schema.peer, branch=branch, duplicate=False)
peer_rels = peer_schema.get_relationships_by_identifier(id=relm.schema.get_identifier())
if not peer_rels:
    return  # BUG: silently skips constraint when peer is a generic

With the reported schema:

• InterfaceLayer3.ip_addresses has peer: BuiltinIPAddress, cardinality: many, direction: outbound, identifier: ip__l3interface
• NetworkUnicastIPAddress.layer3 has peer: InterfaceLayer3, cardinality: one, direction: inbound, identifier: ip__l3interface
• NetworkAnycastIPAddress.layer3 has peer: InterfaceLayer3, cardinality: many, direction: inbound, identifier: ip__l3interface

When saving a new InterfaceLayer3 that points to a NetworkUnicastIPAddress, the constraint looks up BuiltinIPAddress's relationships for identifier ip__l3interface. BuiltinIPAddress only defines ip_namespace and ip_prefix relationships (see backend/infrahub/core/schema/definitions/core/ipam.py:209); the ip__l3interface relationship belongs to user-defined concrete child types. get_relationships_by_identifier finds nothing, returns [], and the constraint exits early — no cardinality check occurs.

This is why creating a second InterfaceLayer3 pointing to the same NetworkUnicastIPAddress succeeds at write time, but then crashes at read time in manager.py:1316 (raise ValueError("At most, one relationship expected")), which is a defensive assertion in the read path rather than a write-time enforcement gate.

The reporter's observation that the bug only reproduces with BuiltinIPAddress is consistent: the bug triggers whenever the peer declared on the writing side is a generic schema that does not itself define the reverse relationship, deferring it to concrete inheritors.

Fix strategy

Approach: In RelationshipCountConstraint.check() (count.py), after finding that peer_rels is empty, check whether peer_schema.is_generic_schema. If it is, build a peer_id → concrete_kind mapping from relm._relationships by calling rel.get_peer_kind() on each resolved relationship (these are available because relm.resolve() is already called at the top of check()). For each peer being added (peer_ids_present_local_only), look up the relationship schema on the concrete kind's schema rather than the generic's. Apply max_count enforcement as the existing code does. Do the analogous thing for peers being removed (peer_ids_present_database_only / min_count). Apply the same fix to lock_utils.py so the concurrency lock is correctly acquired for generic-typed relationships with cardinality-constrained children.

Scope:

• backend/infrahub/core/relationship/constraints/count.py — extend check() with a fallback that resolves concrete kinds from relm._relationships when peer_rels is empty on a generic peer; roughly 15–25 additional lines
• backend/infrahub/core/node/lock_utils.py — extend get_lock_names_on_object_mutation() with a similar concrete-kind lookup when peer_rel is None due to a generic peer schema; roughly 10–15 additional lines

Do NOT:

• Only fix the read-time ValueError in manager.py:1316 — that is a symptom, not the cause, and masking it would hide data-integrity violations
• Iterate all children of the generic unconditionally and apply the most-restrictive cardinality across all of them; different children can have different cardinalities for the same identifier (cardinality: one for Unicast, cardinality: many for Anycast), so you must use the actual concrete kind of each individual peer node
• Add a query to the DB to resolve peer kinds independently — relm.resolve() is already called and rel.get_peer_kind() returns the concrete kind once resolved; use that instead

Notes for downstream steps

• Relationship.get_peer_kind() (model.py:174) returns self.schema.peer (the generic) if _peer is still unresolved, and self._peer.get_kind() (the concrete kind) when fully resolved. The fix must rely on resolution having happened; it already has because await relm.resolve(db=self.db) is the first line of check().
• The GenericSchema.used_by list (populated during process_generics() in schema_branch.py:1853) is available if you need to enumerate child schemas, but the preferred approach is to derive the kind directly from the resolved relationship, not from used_by, to avoid applying the wrong schema to the wrong peer.
• The lock fix in lock_utils.py is called before resolution, so the concrete kind cannot be read from rel.get_peer_kind() directly there. In that path the relationship's _peer may already be set if the caller assigned a Node object (not just a UUID); otherwise, the fix may need to look up the concrete kind via registry.schema for each kind in peer_schema.used_by and check if any has a constrained reverse relationship, then lock conservatively.
• This bug can produce corrupted data (multiple inbound relationships on a cardinality-one slot) that survives in the database. A data-migration or deduplication script may be needed separately from the code fix, but that is out of scope for the test-writer and fixer tasks.

AGENT_ANALYSIS_COMPLETE

Generated by Bug analyst agent for issue #9 · ● 414.4K · ◷

[polmichel]

/bug-tdd

[github-actions]

✅ Bug test-writer agent completed successfully!

[infrahub-bug-pipeline]

Pull request created: #10

Generated by Bug test-writer agent

[infrahub-bug-pipeline]

A failing test has been written for this issue.

Draft PR: The test PR has been opened from branch ai-bug-pipeline-9-generic-peer-cardinality.

Test: backend/tests/component/core/constraint_validators/test_relationship_manager.py::test_relationship_count_constraint_enforced_for_cardinality_one_on_generic_concrete_child

The test creates a schema mirroring the BuiltinIPAddress / NetworkUnicastIPAddress pattern: a generic peer (TestGenericAddress) that does not define the reverse relationship, with concrete children (TestUnicastAddress) that declare cardinality: one inbound. It asserts that RelationshipCountConstraint raises ValidationError when a second interface is linked to the same unicast address — a check that currently silently passes due to the early return in count.py lines 43–46.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• sensomatic.prefect.io

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "sensomatic.prefect.io"

See Network Configuration for more information.

Generated by Bug test-writer agent for issue #9 · ● 723.7K · ◷

[infrahub-bug-pipeline]

Fix implemented in PR #10.

Root cause addressed: RelationshipCountConstraint.check() exited early when the relationship peer was a generic schema type, because the generic defines no reverse relationships. The fix derives each peer's concrete kind from the already-resolved RelationshipManager._relationships and looks up the count constraint on the concrete child schema instead.

Files changed:

• backend/infrahub/core/relationship/constraints/count.py — core cardinality enforcement fix
• backend/infrahub/core/node/lock_utils.py — matching fix for the concurrency lock path

All 704 backend unit tests pass. Lint (ruff, ty, mypy) clean. The component test test_relationship_count_constraint_enforced_for_cardinality_one_on_generic_concrete_child validates the fix end-to-end (requires Neo4j, passes in CI).

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• sensomatic.prefect.io

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "sensomatic.prefect.io"

See Network Configuration for more information.

Note

🔒 Integrity filter blocked 1 item

The following item was blocked because it doesn't meet the GitHub integrity level.

• #10 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Bug fixer agent for issue #10 · ● 617.4K · ◷