Skip to content

Path tracing broken for front/rear ports in REST API #18991

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
srfwx opened this issue Mar 24, 2025 · 1 comment · Fixed by #19006
Closed

Path tracing broken for front/rear ports in REST API #18991

srfwx opened this issue Mar 24, 2025 · 1 comment · Fixed by #19006
Assignees
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Milestone

Comments

@srfwx
Copy link

srfwx commented Mar 24, 2025

Deployment Type

Self-hosted

NetBox Version

v4.2.6

Python Version

3.12

Steps to Reproduce

  1. Go to https://[SERVER_URL]/api/dcim/rear-ports/
  2. Select any existing port by clicking on its "url"
  3. The REST API now display the data for a single port, for example:
    https://[SERVER_URL]/api/dcim/rear-ports/70479/
  4. Append "paths/" to this URL: https://[SERVER_URL]/api/dcim/rear-ports/70479/paths

Expected Behavior

The REST API should return the CablePaths which traverse the given pass-through port.

Observed Behavior

'AttributeError' is raised.

'NoneType' object has no attribute 'model'

This error is not observed on NetBox 4.2.5
I believe this may have been introduced by #18826 ?

@srfwx srfwx added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Mar 24, 2025
@arthanson arthanson added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation severity: medium Results in substantial degraded or broken functionality for specfic workflows and removed status: needs triage This issue is awaiting triage by a maintainer labels Mar 24, 2025
@jnovinger
Copy link
Member

jnovinger commented Mar 25, 2025

Looking at this now. It appears to work in the feature branch. Not sure what might have "fixed" it. Ah, I think it's as simple as the work for #18826 hasn't been included in feature yet.

@jnovinger jnovinger self-assigned this Mar 25, 2025
@jnovinger jnovinger added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Mar 25, 2025
jnovinger added a commit that referenced this issue Mar 25, 2025
`GenericArrayForeignKey`, which was added in #18826, advertised itself
as a many_to_many relation, which is somewhat inaccurate and triggered
DRF's introspection of many_to_many relations which looks for a
`remote_field.model` property chain on the relation. Since that doesn't
exist, DRF threw an AttributeError resulting in a 500 error.

This changes `GenericArrayForeignKey` to advertise itself to DRF as a
one_to_many relation, which is more accurate, and does not trigger the
property access in DRF that was causing the problem.

This also adds a regression test for both FrontPort and RearPort "path"
API view.
@jnovinger jnovinger added this to the v4.2.7 milestone Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants