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

Unexpected results from query GET /api/dcim/cables/ with termination_a_id and termination_a_type query parameters #8844

New Issue
Closed
opened 2025-12-29 20:41:57 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:41:57 +01:00
Owner
Copy Link

Originally created by @thomas-esposito on GitHub (Nov 15, 2023).

NetBox version

v3.6.5

Python version

3.10

Steps to Reproduce

  1. create 2 devices with front ports and a device with interfaces
  2. find ids that overlap (ex: front port id = 2 and interface id = 2)
  3. create a cable from the interface to a front port on the 2nd device (ex: interface 2 to front port 20)
  4. query GET /api/dcim/cables/?termination_a_id=2&termination_a_type=dcim.frontport
  5. review results

Expected Behavior

No cable - in this scenario, front port 2 belonging to device 1 has no cable. Front port 20 belonging to device 2 has a cable to interface 2.

Observed Behavior

The query asks for termination_a_id=2 and termination_a_type=dcim.frontport but returns a cable where termination_a_id=2 and termination_b_type=dcim.frontport

Have also tested this with rear cables. A matching id on the A side and matching type on the B side will return a cable. Can also confirm b termination queries yield similar behavior:

GET /api/dcim/cables/?termination_b_id=4&termination_b_type=dcim.frontport
results in (trimmed):

{
    "count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "a_terminations": [
                {
                    "object_type": "dcim.frontport",
                    "object_id": 12
                }
            ],
            "b_terminations": [
                {
                    "object_type": "dcim.interface",
                    "object_id": 4
                }
            ],
            "status": {
                "value": "connected",
                "label": "Connected"
            }
        }
    ]
}
Originally created by @thomas-esposito on GitHub (Nov 15, 2023). ### NetBox version v3.6.5 ### Python version 3.10 ### Steps to Reproduce 1. create 2 devices with front ports and a device with interfaces 2. find ids that overlap (ex: front port id = 2 and interface id = 2) 3. create a cable from the interface to a front port on the 2nd device (ex: interface 2 to front port 20) 4. query `GET /api/dcim/cables/?termination_a_id=2&termination_a_type=dcim.frontport` 5. review results ### Expected Behavior No cable - in this scenario, front port 2 belonging to device 1 has no cable. Front port 20 belonging to device 2 has a cable to interface 2. ### Observed Behavior The query asks for termination_a_id=2 and termination_a_type=dcim.frontport but returns a cable where termination_a_id=2 and **termination_b_type=dcim.frontport** Have also tested this with rear cables. A matching id on the A side and matching type on the B side will return a cable. Can also confirm b termination queries yield similar behavior: `GET /api/dcim/cables/?termination_b_id=4&termination_b_type=dcim.frontport` results in (trimmed): ``` { "count": 1, "next": null, "previous": null, "results": [ { "a_terminations": [ { "object_type": "dcim.frontport", "object_id": 12 } ], "b_terminations": [ { "object_type": "dcim.interface", "object_id": 4 } ], "status": { "value": "connected", "label": "Connected" } } ] } ```
adam added the type: bugseverity: medium labels 2025-12-29 20:41:57 +01:00
adam closed this issue 2025-12-29 20:41:57 +01:00
adam commented 2025-12-29 20:41:58 +01:00
Author
Owner
Copy Link

@thomas-esposito commented on GitHub (Nov 15, 2023):

Issue discovered when querying for existing cables and got back confusing results about a connection between different locations and between unexpected device types for a front port that appeared to have no connection when viewed in netbox

@thomas-esposito commented on GitHub (Nov 15, 2023): Issue discovered when querying for existing cables and got back confusing results about a connection between different locations and between unexpected device types for a front port that appeared to have no connection when viewed in netbox
adam commented 2025-12-29 20:41:58 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Nov 15, 2023):

I can confirm this, and it's a duplicate of this issue:

https://github.com/netbox-community/netbox/issues/10615

I never followed up as so much time passed, but it seem like the PR fixed this extra note in the issue instead of the actual issue:

termination_b_type/termination_b_id and termination_a_type/termination_a_id also matches the same thing, not sure if this is intended and the a/b end are just for ease of visualization.

@kkthxbye-code commented on GitHub (Nov 15, 2023): I can confirm this, and it's a duplicate of this issue: https://github.com/netbox-community/netbox/issues/10615 I never followed up as so much time passed, but it seem like the PR fixed this extra note in the issue instead of the actual issue: > termination_b_type/termination_b_id and termination_a_type/termination_a_id also matches the same thing, not sure if this is intended and the a/b end are just for ease of visualization.
adam commented 2025-12-29 20:41:58 +01:00
Author
Owner
Copy Link

@thomas-esposito commented on GitHub (Nov 15, 2023):

I saw that issue but did not realize it was the same, my mistake. If this ends up not being a valid issue, for any future viewers, my team is working around this issue by filtering the filtered results:

Step 1: query for termination_a_id = 5 and termination_a_type = dcim.frontport
Step 2: check that the resulting cables are actually id = 5 and type = dcim.frontport on termination A

Maybe a comment should be added to the original issue, but I would most certainly think this is an issue. The circumstance in which we discovered the behavior suggests so to me, at least. We asked for specifics on one end of a potentially existing cable and got results for a mix of both ends of a different cable.

If asking for termination_a_id = 5 and termination_a_type = dcim.frontport yields the same cable as:

  • termination_a_id = 5 and termination_a_type = dcim.interface
  • termination_a_id = 5 and termination_b_type = dcim.frontport

Surely that is undesirable behavior

@thomas-esposito commented on GitHub (Nov 15, 2023): I saw that issue but did not realize it was the same, my mistake. If this ends up not being a valid issue, for any future viewers, my team is working around this issue by filtering the filtered results: Step 1: query for termination_a_id = 5 and termination_a_type = dcim.frontport Step 2: check that the resulting cables are actually id = 5 and type = dcim.frontport on termination A Maybe a comment should be added to the original issue, but I would most certainly think this is an issue. The circumstance in which we discovered the behavior suggests so to me, at least. We asked for specifics on one end of a potentially existing cable and got results for a mix of both ends of a different cable. If asking for termination_a_id = 5 and termination_a_type = dcim.frontport yields the same cable as: - termination_a_id = 5 and termination_a_type = dcim.interface - termination_a_id = 5 and termination_b_type = dcim.frontport Surely that is undesirable behavior
adam commented 2025-12-29 20:41:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 5, 2023):

Rather than attempt to fix the current logic, it would probably be easier and provide for a better user experience to implement an alternative set of filters for cables. I've opened FR #14434 to propose this, and will mark this as blocked pending the outcome of that discussion.

@jeremystretch commented on GitHub (Dec 5, 2023): Rather than attempt to fix the current logic, it would probably be easier and provide for a better user experience to implement an alternative set of filters for cables. I've opened FR #14434 to propose this, and will mark this as blocked pending the outcome of that discussion.
adam commented 2025-12-29 20:41:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 28, 2023):

Following up on the above, #14434 has been completed and will be included in the v3.7.0 release. IMO these new filters offer a much more convenient means of filtering cables by a specific termination object.

@jeremystretch commented on GitHub (Dec 28, 2023): Following up on the above, #14434 has been completed and will be included in the v3.7.0 release. IMO these new filters offer a much more convenient means of filtering cables by a specific termination object.
adam commented 2025-12-29 20:41:59 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Feb 2, 2024):

@jeremystretch can this be closed then as resolved in 3.7? Also https://github.com/netbox-community/netbox/issues/10615

@arthanson commented on GitHub (Feb 2, 2024): @jeremystretch can this be closed then as resolved in 3.7? Also https://github.com/netbox-community/netbox/issues/10615
adam commented 2025-12-29 20:42:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 2, 2024):

I think so. Just to drive this home, the above example

GET /api/dcim/cables/?termination_b_id=4&termination_b_type=dcim.frontport

would become

GET /api/dcim/cables/?frontport_id=4

I'm going to close this out as there's been no further discussion and IMO the root use case is satisfied by the new filters. Thanks for calling that out @arthanson.

@jeremystretch commented on GitHub (Feb 2, 2024): I think so. Just to drive this home, the above example ``` GET /api/dcim/cables/?termination_b_id=4&termination_b_type=dcim.frontport ``` would become ``` GET /api/dcim/cables/?frontport_id=4 ``` I'm going to close this out as there's been no further discussion and IMO the root use case is satisfied by the new filters. Thanks for calling that out @arthanson.
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 severity: medium 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#8844
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?