Index/Constraint naming collision

[hkeidesen]

Plugin Version

0.7.1

NetBox Version

4.4.1

Python Version

3.11

Steps to Reproduce

1. Create a plugin with models that have ForeignKey fields and/or UniqueConstraints
2. Install NetBox Branching 0.7.1
3. Create a new branch via the API or UI
4. Observe the error in the job logs

Expected Behavior

The branch should provision successfully, as it did with version 0.5.4.

Observed Behavior

The branch provisioning fails with index/constraint naming collisions.

[hkeidesen]

We tracked the branch provisioning errors down to duplicate indexes on some models.

Django automatically creates an index for every ForeignKey. If the same field is also included in a UniqueConstraint, you end up with two indexes on the same FK column:

1. A non-unique index from the ForeignKey itself.

2. A unique index from the UniqueConstraint.

Index names are normalized during branch provisioning. If a model ends up with two indexes on the same foreign key column (one from the FK itself and one from a UniqueConstraint), the normalization process treats them as identical. That causes a conflict when the migration tries to rename the index, since the target name is already taken.

Fix

On affected models, we set:

foreignkey_field = models.ForeignKey(
    "OtherModel",
    on_delete=models.CASCADE,
    db_index=False,  # prevent duplicate non-unique index
)

That way only the unique index from the constraint is created, and the collision disappears.

Notes

• This only applies when the UniqueConstraint covers exactly the FK field alone.
• For composite constraints (fields=['a', 'b']), Django still needs the FK index, so don’t disable it unless you know it overlaps.
• Alternatively, if the relationship is inherently one-to-one, you can switch to OneToOneField (which only creates a unique index).

[arthanson]

@hkeidesen do you have a minimal plugin that shows the issue? If so can you please attach it?

[hkeidesen]

Sorry, the comment was meant to close the issue as it was on our end, since we defined two db indexes on some fields. That caused the provisioning to get confused.