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

Interface-connections filter only searches lowest PK interface device #4467

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

Originally created by @ajmyyra on GitHub (Jan 14, 2021).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.9.1
  • NetBox version: 2.10.3

Steps to Reproduce

API endpoint for listing interface connection seems to have broken between versions 2.9 and 2.10.

  1. Create two devices with a connection between their interfaces, starting from the first device.
  2. Try using hostname with /api/dcim/interface-connections/?device=HOSTNAME and get HTTP error 500
  3. Try listing interfaces for the second device with /api/dcim/interface-connections/?device_id=2 (or whatever id you have) and get an empty list.

Expected Behavior

You could previously fetch device's interface connections with /api/dcim/interface-connections/?device=HOSTNAME or with /api/dcim/interface-connections/?device_id=1337 . API should return all connections where the device is a part of, no matter the end of cable the device is in (so both interface_a and interface_b). This behaviour is still standard in the web interface where all connections are shown under /dcim/devices/1337/interfaces/ .

Observed Behavior

Using the interface-connections endpoint with ?device=HOSTNAME returns ValueError with a HTTP status of 500 and the error message of "Field 'id' expected a number but got 'server01'."

Looking at the commits for 2.10 (this for example), it seems like searching with a name has been deprecated and you can actually use both device or device_id to list the connections when you specify the id. This however works only for listing connections that have their first end (interface_a) as that device. As I expect to use the API endpoint (and can use the web interface) to see all connections to and from that device, I consider this a bug.

Originally created by @ajmyyra on GitHub (Jan 14, 2021). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.9.1 * NetBox version: 2.10.3 ### Steps to Reproduce API endpoint for listing interface connection seems to have broken between versions 2.9 and 2.10. 1. Create two devices with a connection between their interfaces, starting from the first device. 2. Try using hostname with **/api/dcim/interface-connections/?device=HOSTNAME** and get HTTP error 500 3. Try listing interfaces for the second device with **/api/dcim/interface-connections/?device_id=2** (or whatever id you have) and get an empty list. ### Expected Behavior You could previously fetch device's interface connections with **/api/dcim/interface-connections/?device=HOSTNAME** or with **/api/dcim/interface-connections/?device_id=1337** . API should return all connections where the device is a part of, no matter the end of cable the device is in (so both **interface_a** and **interface_b**). This behaviour is still standard in the web interface where all connections are shown under **/dcim/devices/1337/interfaces/** . ### Observed Behavior Using the interface-connections endpoint with ?device=HOSTNAME returns ValueError with a HTTP status of 500 and the error message of **"Field 'id' expected a number but got 'server01'."** Looking at the commits for 2.10 ([this](https://github.com/netbox-community/netbox/commit/079c42291c132e46d61125eef46e90d59403b739) for example), it seems like searching with a name has been deprecated and you can actually use both **device** or **device_id** to list the connections when you specify the id. This however works only for listing connections that have their first end (interface_a) as that device. As I expect to use the API endpoint (and can use the web interface) to see all connections to and from that device, I consider this a bug.
adam added the type: bugstatus: accepted labels 2025-12-29 18:36:17 +01:00
adam closed this issue 2025-12-29 18:36:17 +01:00
adam commented 2025-12-29 18:36:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 19, 2021):

Try using hostname with /api/dcim/interface-connections/?device=HOSTNAME and get HTTP error 500

Looks like you've encountered two different issues. I've opened #5639 to address the error when filtering by device name.

@jeremystretch commented on GitHub (Jan 19, 2021): > Try using hostname with /api/dcim/interface-connections/?device=HOSTNAME and get HTTP error 500 Looks like you've encountered two different issues. I've opened #5639 to address the error when filtering by device name.
adam commented 2025-12-29 18:36:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 13, 2021):

These views are due to be removed under #5223 as they no longer serve much of a purpose (they predate cabling support). Not sure it's worth the effort pursuing this.

@jeremystretch commented on GitHub (Apr 13, 2021): These views are due to be removed under #5223 as they no longer serve much of a purpose (they predate cabling support). Not sure it's worth the effort pursuing this.
adam commented 2025-12-29 18:36:18 +01:00
Author
Owner
Copy Link

@kjellrg commented on GitHub (Apr 28, 2021):

We upgraded from v2.9.4 to v2.11.2 and are experiencing this issue as well. We are not getting an HTTP 500 error, but the response is an empty or incomplete list.

  • Both /api/dcim/interface-connections/?device=HOSTNAME and /api/dcim/interface-connections/?device_id=ID returns an empty list, unless the specified hostname/device_id is on the "interface_a" side of things.

We are not able to consistently specify what is in the "interface_a" of a link, so this will return an incomplete result in most cases.

The v2.11.2 instance is running a copy of the v2.9.4 database and manage.py migrate" has been run. In the UI we can see and trace all connections correctly in v2.11.2

v2.9.4:
In [35]: len(netbox.dcim.get_interface_connections(device="sw00027"))
Out[35]: 29

v2.11.2
In [36]: len(netboxdevel.dcim.get_interface_connections(device="sw00027"))
Out[36]: 0
@kjellrg commented on GitHub (Apr 28, 2021): We upgraded from v2.9.4 to v2.11.2 and are experiencing this issue as well. We are not getting an HTTP 500 error, but the response is an empty or incomplete list. * Both <b>/api/dcim/interface-connections/?device=HOSTNAME</b> and <b>/api/dcim/interface-connections/?device_id=ID</b> returns an empty list, unless the specified hostname/device_id is on the "interface_a" side of things. We are not able to consistently specify what is in the "interface_a" of a link, so this will return an incomplete result in most cases. The v2.11.2 instance is running a copy of the v2.9.4 database and **manage.py migrate**" has been run. In the UI we can see and trace all connections correctly in v2.11.2 ``` v2.9.4: In [35]: len(netbox.dcim.get_interface_connections(device="sw00027")) Out[35]: 29 v2.11.2 In [36]: len(netboxdevel.dcim.get_interface_connections(device="sw00027")) Out[36]: 0 ```
adam commented 2025-12-29 18:36:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 28, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 28, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:36:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 8, 2021):

Maybe we should just remove the duplicate filtering from the interface connections view. That will return all end-to-end connections (typically doubling the number currently returned), but will ensure that filtering is applied consistently.

@jeremystretch commented on GitHub (Jul 8, 2021): Maybe we should just remove the duplicate filtering from the interface connections view. That will return _all_ end-to-end connections (typically doubling the number currently returned), but will ensure that filtering is applied consistently.
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 status: accepted type: bug
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#4467
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?