What happens
After a successful synchronization creates physical interfaces with a bundle
relationship to a LAG, the next diff or sync fails while loading the Infrahub
destination.
The destination contains the complete relationship, but extraction receives a shallow
representation of the referenced InterfaceLag without its device identity component.
The command exits before producing a plan:
PeerIdentifierError: Cannot build unique_id for peer InterfaceLag
(relationship InterfacePhysical.bundle): missing identifier key(s) ['device'];
required identifiers=['device', 'name']
The failure occurs during destination extraction, before a plan is created or any
destination write is attempted. No data corruption has been observed.
What should happen
A destination populated by a previous successful synchronization must remain loadable.
Subsequent diff and sync commands should preserve the physical-interface-to-LAG
relationship and report no create or update operations for converged rows.
Steps to reproduce
-
Start with a clean Infrahub destination and load the required schema.
-
Create a bounded NetBox synchronization project whose InterfacePhysical mapping
includes this field:
- name: bundle
mapping: lag
reference: InterfaceLag
-
Generate the project:
uv run infrahub-sync generate \
--name bounded-netbox \
--directory /path/to/sync-projects
-
Run the first authorized synchronization. It succeeds and creates physical interfaces,
including at least one whose bundle points to an InterfaceLag:
uv run infrahub-sync sync \
--name bounded-netbox \
--directory /path/to/sync-projects
-
Start a fresh command and load the converged destination again:
uv run infrahub-sync diff \
--name bounded-netbox \
--directory /path/to/sync-projects
-
Observe that destination extraction exits with PeerIdentifierError instead of
producing a converged diff.
The failure can also be reproduced by loading only the Infrahub destination; it does not
depend on constructing or contacting the NetBox source adapter.
Why it fails
The Infrahub adapter populates one shared SDK node store while loading mapped kinds in
order. It first stores a fully hydrated InterfaceLag, including the device relationship
required by the DiffSync identity. Loading InterfacePhysical later stores a different,
shallow representation of that same LAG from the nested bundle payload. UUID lookup then
returns the shallow object, whose missing device relationship is not detected by the
adapter's scalar-attribute completeness check.
This is primarily an Infrahub adapter correctness issue: the adapter knows the peer's
required identity fields and must not build an identity from an incomplete stored node.
The SDK store's replacement semantics are a secondary hardening boundary.
Environment
- infrahub-sync
main:
9edc1bc59fb55284094370c5686c3e2aa5f5ac4b (direct live reproduction)
- infrahub-sync
feature/v3-develop:
8ba0c57a7601bd0ffc75431488d6b59717217de6 (confirmed by the earlier live
reproduction on descendant 645d5f4a666de3afe81411c59948f5c0b136549d; the
Infrahub adapter and SDK lock are identical across that range)
- infrahub-sdk:
1.18.1
- Extraction mode: full extraction
- Destination schema: schema-library
bgi-schema-library-v2
Workaround
Removing InterfacePhysical.bundle from the mapping allows destination extraction to
complete, but LAG membership is then no longer synchronized.
sync --continue-on-error is not a convergence workaround: it skips the peer relationship
and can produce phantom relationship updates.
References
What happens
After a successful synchronization creates physical interfaces with a
bundlerelationship to a LAG, the next
difforsyncfails while loading the Infrahubdestination.
The destination contains the complete relationship, but extraction receives a shallow
representation of the referenced
InterfaceLagwithout itsdeviceidentity component.The command exits before producing a plan:
The failure occurs during destination extraction, before a plan is created or any
destination write is attempted. No data corruption has been observed.
What should happen
A destination populated by a previous successful synchronization must remain loadable.
Subsequent
diffandsynccommands should preserve the physical-interface-to-LAGrelationship and report no create or update operations for converged rows.
Steps to reproduce
Start with a clean Infrahub destination and load the required schema.
Create a bounded NetBox synchronization project whose
InterfacePhysicalmappingincludes this field:
Generate the project:
Run the first authorized synchronization. It succeeds and creates physical interfaces,
including at least one whose
bundlepoints to anInterfaceLag:Start a fresh command and load the converged destination again:
Observe that destination extraction exits with
PeerIdentifierErrorinstead ofproducing a converged diff.
The failure can also be reproduced by loading only the Infrahub destination; it does not
depend on constructing or contacting the NetBox source adapter.
Why it fails
The Infrahub adapter populates one shared SDK node store while loading mapped kinds in
order. It first stores a fully hydrated
InterfaceLag, including thedevicerelationshiprequired by the DiffSync identity. Loading
InterfacePhysicallater stores a different,shallow representation of that same LAG from the nested
bundlepayload. UUID lookup thenreturns the shallow object, whose missing
devicerelationship is not detected by theadapter's scalar-attribute completeness check.
This is primarily an Infrahub adapter correctness issue: the adapter knows the peer's
required identity fields and must not build an identity from an incomplete stored node.
The SDK store's replacement semantics are a secondary hardening boundary.
Environment
main:9edc1bc59fb55284094370c5686c3e2aa5f5ac4b(direct live reproduction)feature/v3-develop:8ba0c57a7601bd0ffc75431488d6b59717217de6(confirmed by the earlier livereproduction on descendant
645d5f4a666de3afe81411c59948f5c0b136549d; theInfrahub adapter and SDK lock are identical across that range)
1.18.1bgi-schema-library-v2Workaround
Removing
InterfacePhysical.bundlefrom the mapping allows destination extraction tocomplete, but LAG membership is then no longer synchronized.
sync --continue-on-erroris not a convergence workaround: it skips the peer relationshipand can produce phantom relationship updates.
References
adapter peer-resolution work, but it is not a duplicate: adapter: self-referential relationships abort the Infrahub load with ObjectNotFound #156 concerns a DiffSync
LocalStoremiss for same-kind relationships; this issue concerns a shallow SDK-storereplacement that removes a required cross-kind identity component.
reports relationships missing from nodes retrieved from the SDK store. It may share an
SDK hardening seam, but it does not cover Infrahub Sync's deterministic second-cycle crash
or the adapter's responsibility to validate relationship-valued identity components.