**WIP** fix: Support attribute assignment of cardinality-many relationships#1154
Draft
PhillSimonds wants to merge 2 commits into
Draft
**WIP** fix: Support attribute assignment of cardinality-many relationships#1154PhillSimonds wants to merge 2 commits into
PhillSimonds wants to merge 2 commits into
Conversation
Assigning to a cardinality-many relationship attribute (e.g. `node.members = [peer]`) previously fell through `__setattr__` to `super().__setattr__`, shadowing the RelationshipManager with a raw value. The node then failed in `save()` with a confusing `'InfrahubNode' object has no attribute 'initialized'` error. `__setattr__` now handles cardinality-many relationships: a list rebuilds the RelationshipManager (marked as updated so save() persists it), and a non-list value raises the existing "expects a list of nodes" error at assignment time. Applied to both InfrahubNode and InfrahubNodeSync. Fixes #1152 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deploying infrahub-sdk-python with
|
| Latest commit: |
9beed45
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://388d8111.infrahub-sdk-python.pages.dev |
| Branch Preview URL: | https://sts-fix-1152-many-rel-assign.infrahub-sdk-python.pages.dev |
Codecov Report❌ Patch coverage is
@@ Coverage Diff @@
## develop #1154 +/- ##
===========================================
- Coverage 82.35% 75.51% -6.84%
===========================================
Files 138 138
Lines 12065 12060 -5
Branches 1805 1809 +4
===========================================
- Hits 9936 9107 -829
- Misses 1573 2401 +828
+ Partials 556 552 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 34 files with indirect coverage changes 🚀 New features to boost your workflow:
|
PhillSimonds
marked this pull request as draft
July 10, 2026 03:32
Add coverage that a list assigned to a many-relationship after construction is carried through the save() payload: - test_cardinality_many_assignment_included_in_input_data asserts the peers are present in _generate_input_data() (the build path that previously crashed, and a guard that _strip_unmodified keeps the assignment via has_update). - test_cardinality_many_assignment_saved calls save() with a mocked mutation and asserts the node is persisted and the peers are sent in the request. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes #1152.
Assigning to a cardinality-many relationship attribute (e.g.
node.members = [peer]) previously fell throughInfrahubNode.__setattr__tosuper().__setattr__, storing the raw value as a normal attribute and not correctly wrapping the object in aRelationshipManager. The node then failed insave()with the confusing'list' object has no attribute 'initialized'error. This behavior is different than instantiating an object via .create() with a list passed intodata=, which correctly used .setattr to construct a RelationshipManager and doesn't fall through tosuper().__setattr__.Change
__setattr__now handles cardinality-many relationships (bothInfrahubNodeandInfrahubNodeSync):RelationshipManagerfrom the value and marks it_has_updatesosave()actually persists it;"expects a list of nodes"error from theRelationshipManagerconstructor, at assignment time rather than deferred tosave().Tests
Added to
tests/unit/sdk/test_node.py(async + sync):test_cardinality_many_assignment_requires_list— single node/dict assignment raises"expects a list of nodes".test_cardinality_many_assignment_accepts_list— list assignment populates peers and setshas_update.uv run invoke format lint-codeclean;uv run pytest tests/unit/sdk/test_node.py→ 226 passed.Related
Same relationship-editing ergonomics area as #1031 and the sibling PR for #1153.
Summary by cubic
Fixes assignment to cardinality-many relationships so list assignments populate the manager and non-list values fail fast, eliminating the confusing
'InfrahubNode' object has no attribute 'initialized'save-time error. Applies to both async and sync nodes.__setattr__forInfrahubNodeandInfrahubNodeSync._has_update, and is included in mutation payloads.save()path for both clients.Written for commit 9beed45. Summary will update on new commits.