Summary

When a proposed change runs, Infrahub decides which artifacts (or generator instances) need to be re-rendered. If the artifact/generator definition's GraphQL query targets a single object, only the artifacts for the actually-changed objects are regenerated. Otherwise Infrahub falls back to regenerating every artifact in the definition's target group and logs:

Artifact definition <name> query does not guarantee unique targets. All targets will be processed.

This fallback is triggered even when the query does unambiguously target a single object, as long as it does so via anything other than the simplest possible uniqueness key. Specifically, the query is treated as non-unique whenever it filters by:

• a composite uniqueness constraint (more than one field in the constraint, e.g. namespace__value + name__value),
• a node that has more than one uniqueness constraint defined (even when the query fully satisfies one of them by a single field),
• a uniqueness constraint that includes a relationship component (e.g. uniqueness on name__value + site), or
• the node's human-friendly ID (hfid: filter).

Only two cases are currently recognized as targeting a unique object: a filter by ids: with a single required ID, or a filter by a node whose schema has exactly one uniqueness constraint consisting of exactly one attribute, where the filter argument matches that single attribute.

Conditions to reproduce

1. Define a schema node with a composite or multiple uniqueness constraint (e.g. uniqueness_constraints: [["namespace__value", "name__value"]], or [["name__value"], ["identifier__value"]]), or one that includes a relationship.
2. Create an artifact definition (or generator definition) whose GraphQL query filters that node by the uniqueness key (or by hfid).
3. Open a proposed change that modifies a single object of that kind.
4. Observe that the artifact validator logs the "does not guarantee unique targets" warning and regenerates artifacts for all members of the target group, not just the changed object.

Impact on users

• Slow proposed changes on large groups. A one-object change forces regeneration and re-validation of every artifact in the definition's group. For definitions targeting hundreds or thousands of objects, a trivial edit triggers a full re-render.
• Worsens silently when a schema gains a second uniqueness constraint. A definition whose query was previously scoped correctly (single single-field constraint) starts regenerating all targets the moment a second uniqueness constraint is added to the node's schema — with no change to the query or the definition itself.
• No way to opt into scoped regeneration for common modeling patterns. Composite natural keys, relationship-scoped uniqueness (e.g. "name unique within a site"), and HFID-based filtering are standard, recommended schema patterns, yet none of them benefit from targeted regeneration.
• Increased load and longer feedback loops on every affected proposed change, proportional to group size rather than to the size of the actual change.

Additional information

The uniqueness determination is the only_has_unique_targets check used when validating artifact generation during a proposed change. It currently recognizes a query as single-target only when:

• the query filters by a required, single-valued ids: argument, or
• the targeted node's schema has exactly one uniqueness constraint, that constraint has exactly one component, and a required filter argument's name equals that component.

It does not account for uniqueness constraints made of multiple components, nodes carrying more than one uniqueness constraint, constraints that reference relationships, or filtering by hfid. The fallback path (regenerate all targets) is always functionally correct — the issue is scope/performance, not incorrect output.