Component
Infrahub SDK version
1.19.0
Current Behavior
When using a custom GraphQL query (e.g., in a transform) that includes a cardinality-one relationship like ip_prefix on IpamIPAddress, the SDK fails to deserialize the response with one of two errors:
- If
__typename is included in the query under the relationship: Error: Unable to find the schema 'NestedEdgedBuiltinIPPrefix'
- If
__typename is removed: ValueError: Unable to determine the type of the node, __typename not present in data
Additionally, the initialized property on the RelatedNode for such relationships always returns False, even when the data is present in the GraphQL response.
Expected Behavior
The SDK should correctly strip GraphQL wrapper type prefixes (NestedEdged, Edged, etc.) from __typename values when looking up schemas. The RelatedNode should be properly initialized with the data from the response.
Steps to Reproduce
- Define a GraphQL query that includes a cardinality-one relationship (e.g.,
ip_prefix on an IP address node)
- Include
__typename in the relationship's response fields
- Execute the query via a transform or
execute_graphql
- The SDK will fail with
SchemaNotFoundError when trying to look up NestedEdgedBuiltinIPPrefix
Example query fragment:
ip_prefix {
__typename
node {
... on IpamIPPrefix {
__typename
id
}
}
}
Additional Information
The root cause is in InfrahubNode.from_graphql(). The method extracts __typename from the GraphQL response data:
node_kind = data.get("__typename") or data.get("node", {}).get("__typename", None)
For cardinality-one relationships, the GraphQL API returns a NestedEdged{Kind} wrapper type (e.g., NestedEdgedBuiltinIPPrefix). The outer __typename is truthy, so the inner node's actual __typename (e.g., BuiltinIPPrefix) is never reached. The schema lookup then fails because NestedEdgedBuiltinIPPrefix is a GraphQL wrapper type, not a registered schema kind.
The existing code in RelatedNodeBase.__init__ already strips the Related prefix for legacy non-paginated responses, but does not handle NestedEdged, Edged, NestedPaginated, or Paginated prefixes.
Component
Infrahub SDK version
1.19.0
Current Behavior
When using a custom GraphQL query (e.g., in a transform) that includes a cardinality-one relationship like
ip_prefixonIpamIPAddress, the SDK fails to deserialize the response with one of two errors:__typenameis included in the query under the relationship:Error: Unable to find the schema 'NestedEdgedBuiltinIPPrefix'__typenameis removed:ValueError: Unable to determine the type of the node, __typename not present in dataAdditionally, the
initializedproperty on theRelatedNodefor such relationships always returnsFalse, even when the data is present in the GraphQL response.Expected Behavior
The SDK should correctly strip GraphQL wrapper type prefixes (
NestedEdged,Edged, etc.) from__typenamevalues when looking up schemas. TheRelatedNodeshould be properly initialized with the data from the response.Steps to Reproduce
ip_prefixon an IP address node)__typenamein the relationship's response fieldsexecute_graphqlSchemaNotFoundErrorwhen trying to look upNestedEdgedBuiltinIPPrefixExample query fragment:
Additional Information
The root cause is in
InfrahubNode.from_graphql(). The method extracts__typenamefrom the GraphQL response data:For cardinality-one relationships, the GraphQL API returns a
NestedEdged{Kind}wrapper type (e.g.,NestedEdgedBuiltinIPPrefix). The outer__typenameis truthy, so the inner node's actual__typename(e.g.,BuiltinIPPrefix) is never reached. The schema lookup then fails becauseNestedEdgedBuiltinIPPrefixis a GraphQL wrapper type, not a registered schema kind.The existing code in
RelatedNodeBase.__init__already strips theRelatedprefix for legacy non-paginated responses, but does not handleNestedEdged,Edged,NestedPaginated, orPaginatedprefixes.