Cable trace does not build up after patchpanel redocumentation

[betadrome]

Deployment Type

Self-hosted

NetBox Version

v3.7.2

Python Version

3.11

Steps to Reproduce

1. document the following connection: device <--> patch panel <--> patch panel <--> device
2. re-document the patch panel connections between the patch panels, e.g. changing the positions of the rear connectors
3. run python3 netbox/manage.py trace_paths to recreate the trace paths
4. problem: trace path only works if I disconnect and reconnect all devices from the patchpanel

Expected Behavior

The trace is built again, recognizes its route via the patch fields and displays a complete trace

Observed Behavior

The trace no longer builds up, only when the cables up to the patchpanel have been deleted and recreated do you have a proper trace again. In addition, you have to re-document all end points, if you only re-document one, you can only see the complete path from that side, from the other side it will not find the absolute end point.

[jeremystretch]

Thank you for opening a bug report. Unfortunately, the information you have provided is not sufficient for someone else to attempt to reproduce the reported behavior. Remember, each bug report must include detailed steps that someone else can follow on a clean, empty NetBox installation to reproduce the exact problem you're experiencing. These instructions should include the creation of any involved objects, any configuration changes, and complete accounting of the actions being taken. Also be sure that your report does not reference data on the public NetBox demo, as that is subject to change at any time by an outside party and cannot be relied upon for bug reports.

[betadrome]

I did some more research and tested the problem a lot more. The problem is a bit bigger than I thought. In principle, it occurs when updating from 3.5.x to 3.7.x. Since v3.6.3 the problem: "cable with multiple connections can't cross module front/rear ports" has been fixed. Since then, two parallel cables can be routed between the same patch panel. This also works perfectly, but only for newly created cables. This means that it does not yet recognize the absolute connection for old cable traces. Only when the cable has been newly created from the first and last active component is the trace properly displayed again for both interface end points. Funnily enough, as soon as the connection between an interface and the first passive element has been re-documented, you can see the complete trace from this interface, but not yet from the other side. As soon as you have recreated the cable from the other side, you can see it from both sides. As already mentioned, this problem no longer occurs to this extent after v3.6.3.

Here again step-by-step:

NetBox Version

Update from 3.5.x to 3.7.x, the problem probably also exists between v3.5.x and 3.6.x but not sure

Steps to reproduce

1. [v3.5.x] Create new devices named like patchpanel1 and patchpanel2, 24 rear ports mapped to 24 front ports (1 to 1 connection)
2. [v3.5.x] Create new devices named like switch1 and switch2, each device has e.g. 1 interface
3. [v3.5.x] Create connection between switch1 and patchpanel1
4. [v3.5.x] Create connection between switch2 and patchpanel2

INFO: before the update parallel cables over a patchpanel where not supported (#11079). Conversely, this means that there were no absolute cable traces between to interfaces with passive cabeling.

5. [v3.7.x] Update NetBox to newer version
6. Cable trace is still broken, after deleting the cables between the first and last active component, the cable trace is displayed properly again

The problem no longer occurs as of v3.6.3, i.e. it only affects connections that were documented before v3.6.3 with multi-termination cabling and parallel cables via patch panels.

Here are some pictures from the problem and what it should look like: (v3.5.x before update)

(v3.7.x after update, before recreate cables)

(v3.7.x after update, after recreate cables)

[jeremystretch]

@opensourceXnetbox would you like to take ownership of this issue and submit a PR?