What happens
When a mapping distinguishes source objects using more fields than the destination uses for uniqueness, several source objects can silently converge onto one destination object.
The shipped NetBox mapping identifies LocationRack with (name, site). The current schema-library model keys LocationRack by name alone. Two same-named racks under different sites therefore generate the same Infrahub upsert identity.
In a bounded reproduction with two sites and two same-named rack operations:
- both writes returned the same rack id;
- one rack persisted instead of two;
- the second write replaced the first rack's
site relationship; and
- repeating both writes still left one rack.
Stable main provides no operator signal before this write. The v3 line warns that the destination cannot distinguish the identities, but the warning does not prevent execution.
What should happen
Distinct source identities should not be silently merged. Both objects should persist when the destination can represent them; otherwise the command should stop before applying ambiguous, lossy writes and explain which mapped identity fields the destination cannot distinguish.
Steps to reproduce
- Load a destination schema where
LocationRack has human-friendly id and uniqueness constraint name__value, with a required site relationship.
- Configure
LocationRack with identifiers: ["name", "site"] as in the shipped NetBox example.
- Provide two sites, each containing a rack with the same name.
- Generate the project, review
diff, and run the authorized synchronization.
- Query
LocationRack by the shared name.
Expected: two racks persist, one for each site, or the synchronization refuses before writing.
Actual: one rack persists, both operations resolve to its id, and its site is the value from the last write.
Environment
- Infrahub Sync
main at 9edc1bc59fb55284094370c5686c3e2aa5f5ac4b.
infrahub-sdk==1.18.1.- Infrahub 1.10.6, image source revision
10996aa8aaabfd5be75a916593c6851a4834d43f.
- Schema-library
bgi-schema-library-v2 at 893be13f465158fdf49ce4133a501c8355d53a32.
- Confirmed with synthetic site/rack data on 2026-08-10; no public-demo data is required.
References
What happens
When a mapping distinguishes source objects using more fields than the destination uses for uniqueness, several source objects can silently converge onto one destination object.
The shipped NetBox mapping identifies
LocationRackwith(name, site). The current schema-library model keysLocationRackbynamealone. Two same-named racks under different sites therefore generate the same Infrahub upsert identity.In a bounded reproduction with two sites and two same-named rack operations:
siterelationship; andStable
mainprovides no operator signal before this write. The v3 line warns that the destination cannot distinguish the identities, but the warning does not prevent execution.What should happen
Distinct source identities should not be silently merged. Both objects should persist when the destination can represent them; otherwise the command should stop before applying ambiguous, lossy writes and explain which mapped identity fields the destination cannot distinguish.
Steps to reproduce
LocationRackhas human-friendly id and uniqueness constraintname__value, with a requiredsiterelationship.LocationRackwithidentifiers: ["name", "site"]as in the shipped NetBox example.diff, and run the authorized synchronization.LocationRackby the shared name.Expected: two racks persist, one for each site, or the synchronization refuses before writing.
Actual: one rack persists, both operations resolve to its id, and its
siteis the value from the last write.Environment
mainat9edc1bc59fb55284094370c5686c3e2aa5f5ac4b.infrahub-sdk==1.18.1.10996aa8aaabfd5be75a916593c6851a4834d43f.bgi-schema-library-v2at893be13f465158fdf49ce4133a501c8355d53a32.References