starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Migrating to 2.5.0+ dcim_interface__connected_interface_id_key duplicate key #2236

New Issue
Closed
opened 2025-12-29 17:24:00 +01:00 by adam · 3 comments
adam commented 2025-12-29 17:24:00 +01:00
Owner
Copy Link

Originally created by @anx-ag on GitHub (Dec 21, 2018).

Environment

  • Python version: 3.4.2
  • NetBox version: 2.4.9

Steps to Reproduce

I've upgraded a clone of my netbox system to Debian Stretch with Python 3.5 and when I try to run the database migrations as part of the upgrade from 2.4.9 to 2.5.0 I'm getting the following errors:

Running migrations:
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying dcim.0064_remove_platform_rpc_client... OK
Applying dcim.0065_front_rear_ports... OK
Applying dcim.0066_cables...
Adding console connections... 208 cables created
Adding power connections... 72 cables created
Adding interface connections... Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/django/db/backends/utils.py", line 85, in _execute
return self.cursor.execute(sql, params)
psycopg2.IntegrityError: duplicate key value violates unique constraint "dcim_interface__connected_interface_id_key"
DETAIL: Key (_connected_interface_id)=(23550) already exists.

When I delete the connection in the old database and retry the migration again after a restore, it fails on a different ID. The newly introduced key constraint seems to be stumbling upon issues in our database that have not been handled by the older netbox versions.
The upgrade then fails and cannot be restarted (at least not with the manage.py script on the CLI). Can I somehow identify all records that will be problematic for the new DB scheme?

Expected Behavior

Working DB migration.

Observed Behavior

Non-working DB migration.

Originally created by @anx-ag on GitHub (Dec 21, 2018). <!-- NOTE: This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.4.2<!-- Example: 3.5.4 --> * NetBox version: 2.4.9<!-- Example: 2.3.6 --> <!-- Describe in detail the steps that someone else can take to reproduce this bug using the current stable release of NetBox (or the current beta release where applicable). --> ### Steps to Reproduce I've upgraded a clone of my netbox system to Debian Stretch with Python 3.5 and when I try to run the database migrations as part of the upgrade from 2.4.9 to 2.5.0 I'm getting the following errors: Running migrations: Applying admin.0003_logentry_add_action_flag_choices... OK Applying dcim.0064_remove_platform_rpc_client... OK Applying dcim.0065_front_rear_ports... OK Applying dcim.0066_cables... Adding console connections... 208 cables created Adding power connections... 72 cables created Adding interface connections... Traceback (most recent call last): File "/usr/local/lib/python3.5/dist-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) psycopg2.IntegrityError: duplicate key value violates unique constraint "dcim_interface__connected_interface_id_key" DETAIL: Key (_connected_interface_id)=(23550) already exists. When I delete the connection in the old database and retry the migration again after a restore, it fails on a different ID. The newly introduced key constraint seems to be stumbling upon issues in our database that have not been handled by the older netbox versions. The upgrade then fails and cannot be restarted (at least not with the manage.py script on the CLI). Can I somehow identify all records that will be problematic for the new DB scheme? <!-- What did you expect to happen? --> ### Expected Behavior Working DB migration. <!-- What happened instead? --> ### Observed Behavior Non-working DB migration.
adam closed this issue 2025-12-29 17:24:00 +01:00
adam commented 2025-12-29 17:24:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 21, 2018):

You have overlapping interface connections defined in the database. Please see my comment here for the steps needed to resolve this.

@jeremystretch commented on GitHub (Dec 21, 2018): You have overlapping interface connections defined in the database. Please see my comment [here](https://github.com/digitalocean/netbox/issues/2696#issuecomment-448649820) for the steps needed to resolve this.
adam commented 2025-12-29 17:24:01 +01:00
Author
Owner
Copy Link

@anx-ag commented on GitHub (Dec 21, 2018):

Thanks, I figured that - but is there a way to find out all possible duplicates with one query? Doing that by trial and error (removing the duplicate, restoring database on the new system, run upgrade again, etc.) could take quite some time depending on the amount of duplicates hidden in the database.

@anx-ag commented on GitHub (Dec 21, 2018): Thanks, I figured that - but is there a way to find out all possible duplicates with one query? Doing that by trial and error (removing the duplicate, restoring database on the new system, run upgrade again, etc.) could take quite some time depending on the amount of duplicates hidden in the database.
adam commented 2025-12-29 17:24:01 +01:00
Author
Owner
Copy Link

@anx-ag commented on GitHub (Jan 9, 2019):

The following query can be used to identity the overlapping interfaces (thanks Admir):

SELECT * FROM dcim_interfaceconnection ic1
JOIN dcim_interfaceconnection ic2 ON ic1.interface_a_id = ic2.interface_b_id
JOIN dcim_interface iface1 ON ic1.interface_a_id = iface1.id
JOIN dcim_interface iface2 ON ic1.interface_b_id = iface2.id
JOIN dcim_device d ON d.id = iface1.device_id

@anx-ag commented on GitHub (Jan 9, 2019): The following query can be used to identity the overlapping interfaces (thanks Admir): SELECT * FROM dcim_interfaceconnection ic1 JOIN dcim_interfaceconnection ic2 ON ic1.interface_a_id = ic2.interface_b_id JOIN dcim_interface iface1 ON ic1.interface_a_id = iface1.id JOIN dcim_interface iface2 ON ic1.interface_b_id = iface2.id JOIN dcim_device d ON d.id = iface1.device_id
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2236
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?