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

Assert error when saving cable and adding a second termination #6665

New Issue
Closed
opened 2025-12-29 19:43:39 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:43:39 +01:00
Owner
Copy Link

Originally created by @DanSheps on GitHub (Jul 14, 2022).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

3.3.0-beta1

Python version

3.10

Steps to Reproduce

  1. Create a site ("Test")
  2. Create a manufacturer ("Panduit")
  3. Create a manufacturer ("Cisco")
  4. Create a device type ("C9200-48T") with "Cisco" manufacturer
  5. Create a device type ("Patch Panel") with "Panduit" manufacturer
  6. Add (1) 12 position rear port to "Patch Panel" ("Splice")
  7. Add (12) front ports to "Patch Panel" ("1-12")
  8. Add (48) 1000base-t interfaces to "C9200-48T" ("Eth1-48")
  9. Create a device role ("Access Switch")
  10. Create a device role ("Fiber Patch Panel")
  11. Create (2) devices of type "Patch Panel" ("P1", "P2") in site "Test" with role "Fiber Patch Panel"
  12. Create (2) devices of type "C9200-48T" ("S1", "S2") in site "Test" with role "Access Switch"
  13. On "Patch Panel", connect rear-port on P1 to rear-port on P2

From this point, there are two options to get to the error:

Option A:

  1. On "S1" connect Eth1 to "P1" port "1"
  2. On "S2" connect Eth1 to "P2" port "1"
  3. Edit the resultant cable from step 15 or 16 and add port "2"

Option B

  1. On "S1" connect Eth1 to "P1" port "1" and "2"
  2. On "S2" connect Eth1 to "P2" port "1"

Expected Behavior

Cable to be updated

Observed Behavior

AssertionError

AssertionError at /dcim/cables/add/
No exception message supplied
Request Method:	POST
Request URL:	http://127.0.0.1:8000/dcim/cables/add/?a_terminations_type=dcim.interface&a_terminations=1620&b_terminations_type=dcim.frontport&return_url=/dcim/devices/107/interfaces/
Django Version:	4.0.6
Exception Type:	AssertionError
Exception Location:	C:\Development\netbox\netbox\netbox\dcim\models\cables.py, line 484, in from_origin
Python Executable:	C:\Development\netbox\venv\Scripts\python.exe
Python Version:	3.10.4
Originally created by @DanSheps on GitHub (Jul 14, 2022). Originally assigned to: @jeremystretch on GitHub. ### NetBox version 3.3.0-beta1 ### Python version 3.10 ### Steps to Reproduce 1. Create a site ("Test") 2. Create a manufacturer ("Panduit") 3. Create a manufacturer ("Cisco") 4. Create a device type ("C9200-48T") with "Cisco" manufacturer 5. Create a device type ("Patch Panel") with "Panduit" manufacturer 6. Add (1) 12 position rear port to "Patch Panel" ("Splice") 7. Add (12) front ports to "Patch Panel" ("1-12") 8. Add (48) 1000base-t interfaces to "C9200-48T" ("Eth1-48") 9. Create a device role ("Access Switch") 10. Create a device role ("Fiber Patch Panel") 11. Create (2) devices of type "Patch Panel" ("P1", "P2") in site "Test" with role "Fiber Patch Panel" 12. Create (2) devices of type "C9200-48T" ("S1", "S2") in site "Test" with role "Access Switch" 13. On "Patch Panel", connect rear-port on P1 to rear-port on P2 From this point, there are two options to get to the error: Option A: 15. On "S1" connect Eth1 to "P1" port "1" 16. On "S2" connect Eth1 to "P2" port "1" 17. Edit the resultant cable from step 15 or 16 and add port "2" Option B 15. On "S1" connect Eth1 to "P1" port "1" and "2" 18. On "S2" connect Eth1 to "P2" port "1" ### Expected Behavior Cable to be updated ### Observed Behavior AssertionError ``` AssertionError at /dcim/cables/add/ No exception message supplied Request Method: POST Request URL: http://127.0.0.1:8000/dcim/cables/add/?a_terminations_type=dcim.interface&a_terminations=1620&b_terminations_type=dcim.frontport&return_url=/dcim/devices/107/interfaces/ Django Version: 4.0.6 Exception Type: AssertionError Exception Location: C:\Development\netbox\netbox\netbox\dcim\models\cables.py, line 484, in from_origin Python Executable: C:\Development\netbox\venv\Scripts\python.exe Python Version: 3.10.4 ```
adam added the type: bugstatus: acceptedbeta labels 2025-12-29 19:43:39 +01:00
adam closed this issue 2025-12-29 19:43:40 +01:00
adam commented 2025-12-29 19:43:40 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 14, 2022):

Haven't dove too far into this, the additional front port appears to not have a value for the property "link". We may need to call refresh_from_db() somewhere or otherwise update the cable field once the cable is saved.

@DanSheps commented on GitHub (Jul 14, 2022): Haven't dove too far into this, the additional front port appears to not have a value for the property "link". We may need to call refresh_from_db() somewhere or otherwise update the cable field once the cable is saved.
adam commented 2025-12-29 19:43:40 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 14, 2022):

I think I see what is happening.

First, we create a cable path from the initating port to the end port. Then it sort of "reflects" back to create the return path. Since there are 2 positions on the return path, it expects a second position however that does not exist.

We may need to find a way to handle this more gracefully then an assert.

OR

We may need to document this behaviour so that there is an awareness, especially for those who want to "upgrade" their fiber maps (they would need to go to both ends and start fresh)

@DanSheps commented on GitHub (Jul 14, 2022): I think I see what is happening. First, we create a cable path from the initating port to the end port. Then it sort of "reflects" back to create the return path. Since there are 2 positions on the return path, it expects a second position however that does not exist. We may need to find a way to handle this more gracefully then an assert. OR We may need to document this behaviour so that there is an awareness, especially for those who want to "upgrade" their fiber maps (they would need to go to both ends and start fresh)
adam commented 2025-12-29 19:43:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 18, 2022):

The root issue is that by adding the second front port to the third cable, we end up with a topology that looks like this:

            /--- [FP1]                       [FP1] --- [Gi1] S1
S2 [Gi1] ---           P2 [RP1] --- [RP2] P1
            \--- [FP2]                       [FP2]

When tracing the path originating from S1 Gi1, it splits at P1 because only one of the two front ports is connected to the cable.

It would probably make sense to move the assertion ahead of the for loop, so that it applies only to the originating set of terminations, and to mark the path as split for any successive iterations.

@jeremystretch commented on GitHub (Jul 18, 2022): The root issue is that by adding the second front port to the third cable, we end up with a topology that looks like this: ``` /--- [FP1] [FP1] --- [Gi1] S1 S2 [Gi1] --- P2 [RP1] --- [RP2] P1 \--- [FP2] [FP2] ``` When tracing the path originating from S1 Gi1, it splits at P1 because only one of the two front ports is connected to the cable. It would probably make sense to move the assertion ahead of the `for` loop, so that it applies only to the _originating_ set of terminations, and to mark the path as split for any successive iterations.
adam commented 2025-12-29 19:43:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 18, 2022):

Should be resolved in the feature branch now. There's still a lingering issue concerning the resolution of previously split paths when updating cables, but I don't think it's directly related to this.

@jeremystretch commented on GitHub (Jul 18, 2022): Should be resolved in the `feature` branch now. There's still a lingering issue concerning the resolution of previously split paths when updating cables, but I don't think it's directly related to this.
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 beta 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#6665
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?