Unable to trace the front-rear port connection after importing connections from CSV #11814

Closed
opened 2025-12-29 21:50:12 +01:00 by adam · 10 comments
Owner

Originally created by @1a11 on GitHub (Nov 6, 2025).

NetBox Edition

NetBox Community

NetBox Version

v4.4.0

Python Version

3.10

Steps to Reproduce

  1. Create two devices with module bays
  2. Create two modules with front and rear ports
  3. Assign each module to it's respectful device
  4. Import Cables:
side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name,side_a_site,side_b_site,label,color,type
01.01.TH.10,dcim.frontport,Serial Port Out,01.01.TH.9,dcim.rearport,Serial Port In,02,02,RS485,Light Green,cat6
  1. Unable to trace the conenction from port to port from both sides A and B

Expected Behavior

The connection should be traceable after the import is completed.

Observed Behavior

The connection is not traceable, instead reporting "No paths found":

Image Image Image Image
Originally created by @1a11 on GitHub (Nov 6, 2025). ### NetBox Edition NetBox Community ### NetBox Version v4.4.0 ### Python Version 3.10 ### Steps to Reproduce 1. Create two devices with module bays 2. Create two modules with front and rear ports 3. Assign each module to it's respectful device 4. Import Cables: ```csv side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name,side_a_site,side_b_site,label,color,type 01.01.TH.10,dcim.frontport,Serial Port Out,01.01.TH.9,dcim.rearport,Serial Port In,02,02,RS485,Light Green,cat6 ``` 5. Unable to trace the conenction from port to port from both sides A and B ### Expected Behavior The connection should be traceable after the import is completed. ### Observed Behavior The connection is not traceable, instead reporting "No paths found": <img width="1621" height="292" alt="Image" src="https://github.com/user-attachments/assets/252e7fb4-1393-4d4d-a66d-a2adf2146798" /> <img width="1630" height="249" alt="Image" src="https://github.com/user-attachments/assets/b88814d9-0076-4648-b265-07aa13722d3d" /> <img width="1630" height="398" alt="Image" src="https://github.com/user-attachments/assets/7a510e14-3094-4f10-be0c-0b3abf5279be" /> <img width="1626" height="203" alt="Image" src="https://github.com/user-attachments/assets/1246a039-aeb5-40f0-93e3-abf3511f88ce" />
adam closed this issue 2025-12-29 21:50:12 +01:00
Author
Owner

@bctiemann commented on GitHub (Nov 6, 2025):

@1a11 Could you please add some detail to your steps 1-3, showing the names and details used for your setup? That would make this issue much easier to reproduce and fix. The less friction there is for a contributor to repro the problem, the better the chance of a fix being developed. Thank you!

@bctiemann commented on GitHub (Nov 6, 2025): @1a11 Could you please add some detail to your steps 1-3, showing the names and details used for your setup? That would make this issue much easier to reproduce and fix. The less friction there is for a contributor to repro the problem, the better the chance of a fix being developed. Thank you!
Author
Owner

@1a11 commented on GitHub (Nov 7, 2025):

Cables exist between the following device types :

  1. Device with rear and front ports created in it specifically:
Image Image Image
  1. Device with rear and front ports created inside it's module:
Image Image

In production:

  • A device of type 2 exists. There is a mulude inside of it, with front and rear ports:
Image Image
  • Module:
Image
    • And it's two ports:
Image Image
@1a11 commented on GitHub (Nov 7, 2025): Cables exist between the following device types : 1) Device with rear and front ports created in it specifically: <img width="1238" height="837" alt="Image" src="https://github.com/user-attachments/assets/2a4c4855-521a-45cc-9776-7d382234acac" /> <img width="1224" height="721" alt="Image" src="https://github.com/user-attachments/assets/442a7036-af0c-4809-908e-a751d71a7ae6" /> <img width="1238" height="830" alt="Image" src="https://github.com/user-attachments/assets/f5fb3212-5a75-4f05-80d6-b95a306577b2" /> 2) Device with rear and front ports created inside it's module: <img width="1222" height="851" alt="Image" src="https://github.com/user-attachments/assets/2bc8b037-7995-42ed-b474-153f95c796bb" /> <img width="1294" height="736" alt="Image" src="https://github.com/user-attachments/assets/cf45479a-e670-4fab-aadd-4ff420b4dc4a" /> In production: - A device of type 2 exists. There is a mulude inside of it, with front and rear ports: <img width="1652" height="733" alt="Image" src="https://github.com/user-attachments/assets/01a1d767-0855-4230-8c09-74cb107fb041" /> <img width="1673" height="335" alt="Image" src="https://github.com/user-attachments/assets/af5aafca-307a-4612-bd0a-09437118363e" /> - Module: <img width="1674" height="654" alt="Image" src="https://github.com/user-attachments/assets/c8f3e06c-b3a4-406b-9629-709a0c4c6c01" /> - - And it's two ports: <img width="1327" height="784" alt="Image" src="https://github.com/user-attachments/assets/d187e411-bc99-4572-844c-4129317c5ce5" /> <img width="1207" height="830" alt="Image" src="https://github.com/user-attachments/assets/b9b3dcc9-1846-426a-bdff-94b51deb2c0f" />
Author
Owner

@1a11 commented on GitHub (Nov 7, 2025):

Module yaml exported:

profile: null
manufacturer: Haier
model: YCJ-A002
part_number: ''
description: "\u041F\u043B\u0430\u0442\u0430 \u0443\u043F\u0440\u0430\u0432\u043B\u0435\
  \u043D\u0438\u044F \u043A\u043E\u043D\u0434\u0438\u0446\u0438\u043E\u043D\u0435\u0440\
  \u043E\u043C"
weight: null
weight_unit: null
comments: ''
front-ports:
- name: Serial Port Out
  type: other
  color: ''
  rear_port: Serial Port In
  rear_port_position: 1
  label: RS485
  description: ''
rear-ports:
- name: Serial Port In
  type: other
  color: ''
  positions: 1
  label: RS485
  description: ''
@1a11 commented on GitHub (Nov 7, 2025): Module yaml exported: ```yaml profile: null manufacturer: Haier model: YCJ-A002 part_number: '' description: "\u041F\u043B\u0430\u0442\u0430 \u0443\u043F\u0440\u0430\u0432\u043B\u0435\ \u043D\u0438\u044F \u043A\u043E\u043D\u0434\u0438\u0446\u0438\u043E\u043D\u0435\u0440\ \u043E\u043C" weight: null weight_unit: null comments: '' front-ports: - name: Serial Port Out type: other color: '' rear_port: Serial Port In rear_port_position: 1 label: RS485 description: '' rear-ports: - name: Serial Port In type: other color: '' positions: 1 label: RS485 description: '' ```
Author
Owner

@1a11 commented on GitHub (Nov 14, 2025):

Is there maybe an update to the behavior?

@1a11 commented on GitHub (Nov 14, 2025): Is there maybe an update to the behavior?
Author
Owner

@jnovinger commented on GitHub (Nov 20, 2025):

@1a11, your extra notes don't seem to be helping me understand this. Can you please update the original steps to reproduce (as in, actually edit the original report). Note the instructions from the bug template:

Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox. Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a client library such as pynetbox. Additionally, do not rely on the demo instance for reproducing suspected bugs, as its data is prone to modification or deletion at any time.

In particular, that first sentence is saying you must provide enough detail, with enough precision, in the right order for a maintainer to be able to reproduce this issue. You must account for every piece of data that this bug depends on. This is the bare minimum. Without that level of detail, we are not able to make progress on this (or any other) reported bug.

I've spent 10 minutes reading your subsequent comment and I'm left with more questions than when I read the initial report. To be very clear, screenshots are absolutely not an acceptable substitute for the level of detail I'm asking for.

@jnovinger commented on GitHub (Nov 20, 2025): @1a11, your extra notes don't seem to be helping me understand this. Can you please update the original steps to reproduce (as in, actually edit the original report). Note the instructions from the bug template: > Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox. Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a client library such as pynetbox. Additionally, do not rely on the demo instance for reproducing suspected bugs, as its data is prone to modification or deletion at any time. In particular, that first sentence is saying you _**must**_ provide enough detail, with enough precision, in the right order for a maintainer to be able to reproduce this issue. You must account for every piece of data that this bug depends on. This is the bare minimum. Without that level of detail, we are not able to make progress on this (or any other) reported bug. I've spent 10 minutes reading your subsequent comment and I'm left with more questions than when I read the initial report. To be very clear, screenshots are absolutely not an acceptable substitute for the level of detail I'm asking for.
Author
Owner

@github-actions[bot] commented on GitHub (Nov 28, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Nov 28, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
Author
Owner

@1a11 commented on GitHub (Dec 3, 2025):

Keeping this open. I will see what other information I can gather on the topic. Issue in current state does describe the steps taken to reproduce the issue on our side. If you could possibly direct me to the specific log file I could export or database dump I should do to give you as much info as possible?

@1a11 commented on GitHub (Dec 3, 2025): Keeping this open. I will see what other information I can gather on the topic. Issue in current state does describe the steps taken to reproduce the issue on our side. If you could possibly direct me to the specific log file I could export or database dump I should do to give you as much info as possible?
Author
Owner

@arthanson commented on GitHub (Dec 8, 2025):

@1a11 You have steps but not details in the steps in your original bug report. I.E. You state:

  1. Create two devices with module bays
  2. Create two modules with front and rear ports
  3. Assign each module to it's respectful device

Provide details here like:

  1. Create a device "xxx" (include any required fields in this that may effect bug report)
  2. Create a device "yyy"
  3. Create a module bay "mb1" on site "xxx", Create a module bay "mb2" on site "yyy"

In step 4 you give a csv that references a bunch of devices, the steps to create these devices and configuration should be given in the above steps and the names should match so we can make sure we are reproducing exactly the steps you are taking. Right now we have to guess and make a lot of assumptions when trying to reproduce this. If an item is referenced in the csv - there should be clear steps to create it in the reproduction steps, so if the csv references "01.01.TH.10" then the steps above should show creating something with "01.01.TH.10".

@arthanson commented on GitHub (Dec 8, 2025): @1a11 You have steps but not details in the steps in your original bug report. I.E. You state: 1. Create two devices with module bays 2. Create two modules with front and rear ports 3. Assign each module to it's respectful device Provide details here like: 1. Create a device "xxx" (include any required fields in this that may effect bug report) 2. Create a device "yyy" 3. Create a module bay "mb1" on site "xxx", Create a module bay "mb2" on site "yyy" In step 4 you give a csv that references a bunch of devices, the steps to create these devices and configuration should be given in the above steps and the names should match so we can make sure we are reproducing exactly the steps you are taking. Right now we have to guess and make a lot of assumptions when trying to reproduce this. If an item is referenced in the csv - there should be clear steps to create it in the reproduction steps, so if the csv references "01.01.TH.10" then the steps above should show creating something with "01.01.TH.10".
Author
Owner

@github-actions[bot] commented on GitHub (Dec 16, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Dec 16, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
Author
Owner

@github-actions[bot] commented on GitHub (Dec 23, 2025):

This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.

@github-actions[bot] commented on GitHub (Dec 23, 2025): This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11814