Component
No response
Infrahub version
1.8.3
Current Behavior
When an instance of a schema node with an IPHost attribute is created and the IPHost attribute is populated, the representation of the value is inconsistent across Infrahub's interfaces:
Web UI: The first column (display label) does not include the CIDR mask on the IPHost value, while the dedicated IPHost attribute column displays a /32 (IPv4) or /128 (IPv6) mask even when no mask was entered at creation time.
GraphQL: Queries that look up an instance by its hfid require the mask to be included in the hfid input, but the hfid returned by the GraphQL query response does not include the mask — making the returned hfid unusable as a direct input for subsequent lookups.
Python SDK: When retrieving the instance via client.get(...), the returned IPHost value includes the /32 or /128 mask, diverging from what the user entered and from what the UI display label shows.
Expected Behavior
The representation of an IPHost attribute should be consistent across the Web UI, GraphQL API, and Python SDK:
The display label, the attribute column in the UI, the hfid returned by GraphQL, and the value returned by the Python SDK should all agree on whether the mask is included.
The hfid returned by a GraphQL query should be directly usable as input for a subsequent hfid-based lookup without the caller needing to re-append /32 or /128.
If no mask was entered at creation time, implicit default masks (/32 for IPv4, /128 for IPv6) should either be applied consistently everywhere or omitted consistently everywhere — not a mix of both.
Steps to Reproduce
- Define a schema node with an IPHost attribute (and include that attribute in the node's human_friendly_id).
- Create an instance of that node, populating the IPHost attribute with a bare address (no mask), e.g. 192.0.2.10.
- Open the instance in the Web UI and observe.
- The first column (display label) shows the address without a mask.
- The IPHost attribute column shows the address with a /32 mask appended.
- Run a GraphQL query to retrieve the instance and note the returned hfid value (mask is absent).
- Attempt to look up the same instance via GraphQL using the returned hfid as input — the query fails unless the mask is re-appended to the hfid.
- Retrieve the same instance using the Python SDK via client.get(...) and observe that the IPHost value returned includes the /32 mask.
Additional Information
The inconsistency appears to stem from different layers applying or stripping the default host mask (/32 for IPv4, /128 for IPv6) independently, rather than a single canonical representation being used when constructing display labels, hfid values, and serialized attribute values
The most user-impacting symptom is the GraphQL hfid round-trip: the value returned by a query cannot be fed back into a lookup without transformation, which breaks common automation patterns.
IPv6 equivalents should be verified to confirm the same /128 behavior occurs in parallel with the /32 IPv4 case.
Component
No response
Infrahub version
1.8.3
Current Behavior
When an instance of a schema node with an IPHost attribute is created and the IPHost attribute is populated, the representation of the value is inconsistent across Infrahub's interfaces:
Web UI: The first column (display label) does not include the CIDR mask on the IPHost value, while the dedicated IPHost attribute column displays a /32 (IPv4) or /128 (IPv6) mask even when no mask was entered at creation time.
GraphQL: Queries that look up an instance by its hfid require the mask to be included in the hfid input, but the hfid returned by the GraphQL query response does not include the mask — making the returned hfid unusable as a direct input for subsequent lookups.
Python SDK: When retrieving the instance via client.get(...), the returned IPHost value includes the /32 or /128 mask, diverging from what the user entered and from what the UI display label shows.
Expected Behavior
The representation of an IPHost attribute should be consistent across the Web UI, GraphQL API, and Python SDK:
The display label, the attribute column in the UI, the hfid returned by GraphQL, and the value returned by the Python SDK should all agree on whether the mask is included.
The hfid returned by a GraphQL query should be directly usable as input for a subsequent hfid-based lookup without the caller needing to re-append /32 or /128.
If no mask was entered at creation time, implicit default masks (/32 for IPv4, /128 for IPv6) should either be applied consistently everywhere or omitted consistently everywhere — not a mix of both.
Steps to Reproduce
Additional Information
The inconsistency appears to stem from different layers applying or stripping the default host mask (/32 for IPv4, /128 for IPv6) independently, rather than a single canonical representation being used when constructing display labels, hfid values, and serialized attribute values
The most user-impacting symptom is the GraphQL hfid round-trip: the value returned by a query cannot be fed back into a lookup without transformation, which breaks common automation patterns.
IPv6 equivalents should be verified to confirm the same /128 behavior occurs in parallel with the /32 IPv4 case.