Skip to content

bug: sub-template instances not updated with new attribute #8722

@ajtmccarty

Description

@ajtmccarty

Component

API Server / GraphQL

Infrahub version

1.8.2

Current Behavior

updating an attribute on a schema that is used as a sub-template (another schema with generate_template=True has a COMPONENT relationship to this schema) does not cause the attribute to be added to existing instances of templates for this schema if generate_template is False on this schema

Expected Behavior

sub-template instances should be correctly updated when a new attribute is added to a schema or an attribute on the schema is updated to be added to the linked template schema

Steps to Reproduce

Reproduction Steps

  1. Define two node schemas: TestDevice with generate_template=True and a Component relationship to TestPart, and TestPart with generate_template=False (default).
  2. Load and process the schema. Observe that TemplateTestPart is automatically generated as a sub-template because TestPart is a Component of TestDevice.
  3. On TestPart, define an attribute (e.g., serial_number) with read_only=True. Because support_templates is read_only is False and unique is False, this attribute is excluded from TemplateTestPart nodes.
  4. Create a TemplateTestPart instance in the database. Confirm it does not have a serial_number attribute.
  5. Update the schema to change TestPart.serial_number from read_only=True to read_only=False. This flips support_templates from False to True.
  6. The schema diff detects attribute.read_only.update and triggers AttributeSupportsGeneratedSchemaMigration.
  7. Expected: The migration adds serial_number to all existing TemplateTestPart nodes.
  8. Actual: The migration silently skips the template update. The condition at backend/infrahub/core/migrations/schema/attribute_supports_generated_schema.py:139 checks self.new_schema.generate_template, which is False for TestPart. The migration only runs for schemas that explicitly set generate_template=True, missing all sub-templates that exist due to Component/Parent relationships from other schemas.

Additional Information

No response

Metadata

Metadata

Assignees

Labels

priority/2This issue stalls work on the project or its dependents, it's a blocker for a releasestate/need-triageThis issue needs to be triagedtype/bugSomething isn't working as expected

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions