You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
infrahubctl object get <kind> does not include cardinality-many relationships of kind Generic in its output — in any output format, even though list mode queries with prefetch_relationships=True. The SDK's query generation only includes many relationships of kind Attribute or Parent by default, and the object get command never passes include for the others.
Example with a TestingPerson node whose animals relationship (cardinality many, kind Generic) has three peers:
The animals relationship is missing entirely — there is no indication in the output or on stderr that data was skipped.
Note: this is about the relationship kindGeneric (the default kind for a relationship in the schema), not about the peer being a generic schema. The peers here are real, instantiated nodes (TestingCat/TestingDog inheriting TestingAnimal).
Expected Behavior
An export intended to be reloadable (object get --output yaml > backup.yml, as shown in the command's own help text) should carry the object's relationships, or at minimum make it visible that some relationships were not exported. Silent omission means a get → load round-trip quietly loses relationship data.
Steps to Reproduce
Load a schema where a node kind has a cardinality-many relationship of kind Generic (e.g. TestingPerson.animals from the SDK's testing schemas).
Create a person and several animals owned by that person.
infrahubctl object get TestingPerson --output yaml
The output contains only attributes; animals is absent.
Reproduced end-to-end with infrahub-testcontainers.
Origin of the behavior: generate_query_data_node (infrahub_sdk/node/node.py) skips many relationships whose kind is not Attribute/Parent unless they are explicitly listed in include; object get (infrahub_sdk/ctl/object/get.py) doesn't pass include. The SDK default is likely a deliberate performance choice (many-rels can be huge), so the gap is in how object get uses it.
Component
infrahubctl
Infrahub SDK version
1.23.0
Current Behavior
infrahubctl object get <kind>does not include cardinality-many relationships of kindGenericin its output — in any output format, even though list mode queries withprefetch_relationships=True. The SDK's query generation only includes many relationships of kindAttributeorParentby default, and theobject getcommand never passesincludefor the others.Example with a
TestingPersonnode whoseanimalsrelationship (cardinality many, kindGeneric) has three peers:The
animalsrelationship is missing entirely — there is no indication in the output or on stderr that data was skipped.Note: this is about the relationship kind
Generic(the default kind for a relationship in the schema), not about the peer being a generic schema. The peers here are real, instantiated nodes (TestingCat/TestingDoginheritingTestingAnimal).Expected Behavior
An export intended to be reloadable (
object get --output yaml > backup.yml, as shown in the command's own help text) should carry the object's relationships, or at minimum make it visible that some relationships were not exported. Silent omission means a get → load round-trip quietly loses relationship data.Steps to Reproduce
Generic(e.g.TestingPerson.animalsfrom the SDK's testing schemas).infrahubctl object get TestingPerson --output yamlanimalsis absent.Reproduced end-to-end with
infrahub-testcontainers.Additional Information
object loadrejects). Together these two issues currently prevent a faithful get → load round-trip.generate_query_data_node(infrahub_sdk/node/node.py) skips many relationships whose kind is notAttribute/Parentunless they are explicitly listed ininclude;object get(infrahub_sdk/ctl/object/get.py) doesn't passinclude. The SDK default is likely a deliberate performance choice (many-rels can be huge), so the gap is in howobject getuses it.