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

[thomas-esposito]

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"
            }
        }
    ]
}

[thomas-esposito]

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

[kkthxbye-code]

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

#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.

[thomas-esposito]

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

[jeremystretch]

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]

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.

[arthanson]

@jeremystretch can this be closed then as resolved in 3.7? Also #10615

[jeremystretch]

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.