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

Missing GraphQL fields #10357

New Issue
Closed
opened 2025-12-29 21:30:27 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:30:27 +01:00
Owner
Copy Link

Originally created by @corubba on GitHub (Oct 12, 2024).

Originally assigned to: @corubba on GitHub.

Deployment Type

Self-hosted

Triage priority

I volunteer to perform this work (if approved)

NetBox Version

v4.1.3

Python Version

3.12

Steps to Reproduce

  1. Open the GraphQL page and execute the following query:
{
  device_list { devicebays { id } }
}

Expected Behavior

I receive a response with a list of all (if any) devices and no errors. This is an example from a v3.7.8 instance with no devices:

{
  "data": {
    "device_list": []
  }
}

Observed Behavior

I receive the following response/error:

{
  "data": null,
  "errors": [
    {   
      "message": "Cannot query field 'devicebays' on type 'DeviceType'. Did you mean 'device_type', 'modulebays', or 'services'?",
      "locations": [
        {
          "line": 2,
          "column": 18
        }
      ]
    }
  ]
}

When I first ran into this, I traced it back to the GraphQL engine switch in the v4.0 release. And because "if it happens once, it may happened twice" I grabbed the GraphQL schemas from a fresh v3.7.8 and v4.1.3 instance, and quickly wrote a script to find all fields and arguments that no longer exist; which were a lot. I had to account for general differences how these engines represent stuff, and filter out all the intended changes (like devicetype_id being renamed to device_type_id). In the end, this handful of unaccounted-for field removals was left:

Type ContactGroupType lost 1 field(s): children:List[ContactGroupType]
Type DeviceType lost 1 field(s): devicebays:List[DeviceBayType]
Type RackType lost 1 field(s): powerfeed_set:List[PowerFeedType]
    and gained 1 field(s): powerfeeds:List[PowerFeedType]
Type SiteType lost 1 field(s): asn:BigInt
Type TenantGroupType lost 1 field(s): children:List[TenantGroupType]
Type WirelessLANGroupType lost 1 field(s): children:List[WirelessLANGroupType]

While I found no matching issue for the Rack change, it looks like a renaming that happened as part of the engine switch, and probably is fine at it is. I am not sure what the Site.asn field was meant to be, because there also is a Site.asns: List[ASN] field; this one is probably also fine as it is. Device missing the devicebays field is the one I initially ran into, which I definitely consider a bug. And then there are the three tree-building self-referential ContactGroup, TenantGroup and WirelessLANGroup which are missing their respective children field; I would also consider this a bug, since others like Location still have their children field.

Originally created by @corubba on GitHub (Oct 12, 2024). Originally assigned to: @corubba on GitHub. ### Deployment Type Self-hosted ### Triage priority I volunteer to perform this work (if approved) ### NetBox Version v4.1.3 ### Python Version 3.12 ### Steps to Reproduce 1. Open the GraphQL page and execute the following query: ``` { device_list { devicebays { id } } } ``` ### Expected Behavior I receive a response with a list of all (if any) devices and no errors. This is an example from a v3.7.8 instance with no devices: ``` { "data": { "device_list": [] } } ``` ### Observed Behavior I receive the following response/error: ``` { "data": null, "errors": [ { "message": "Cannot query field 'devicebays' on type 'DeviceType'. Did you mean 'device_type', 'modulebays', or 'services'?", "locations": [ { "line": 2, "column": 18 } ] } ] } ``` <hr> When I first ran into this, I traced it back to the GraphQL engine switch in the v4.0 release. And because "if it happens once, it may happened twice" I grabbed the GraphQL schemas from a fresh v3.7.8 and v4.1.3 instance, and quickly wrote a script to find all fields and arguments that no longer exist; which were a lot. I had to account for general differences how these engines represent stuff, and filter out all the intended changes (like `devicetype_id` being renamed to `device_type_id`). In the end, this handful of unaccounted-for field removals was left: ``` Type ContactGroupType lost 1 field(s): children:List[ContactGroupType] Type DeviceType lost 1 field(s): devicebays:List[DeviceBayType] Type RackType lost 1 field(s): powerfeed_set:List[PowerFeedType] and gained 1 field(s): powerfeeds:List[PowerFeedType] Type SiteType lost 1 field(s): asn:BigInt Type TenantGroupType lost 1 field(s): children:List[TenantGroupType] Type WirelessLANGroupType lost 1 field(s): children:List[WirelessLANGroupType] ``` While I found no matching issue for the `Rack` change, it looks like a renaming that happened as part of the engine switch, and probably is fine at it is. I am not sure what the `Site.asn` field was meant to be, because there also is a `Site.asns: List[ASN]` field; this one is probably also fine as it is. `Device` missing the `devicebays` field is the one I initially ran into, which I definitely consider a bug. And then there are the three tree-building self-referential `ContactGroup`, `TenantGroup` and `WirelessLANGroup` which are missing their respective `children` field; I would also consider this a bug, since others like `Location` still have their `children` field.
adam added the type: bugstatus: acceptedseverity: low labels 2025-12-29 21:30:27 +01:00
adam closed this issue 2025-12-29 21:30:27 +01:00
adam commented 2025-12-29 21:30:28 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 15, 2024):

@corubba I've assigned this to you. Thanks for volunteering!

@jeremystretch commented on GitHub (Oct 15, 2024): @corubba I've assigned this to you. Thanks for volunteering!
adam commented 2025-12-29 21:30:28 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 16, 2024):

While I found no matching issue for the Rack change, it looks like a renaming that happened as part of the engine switch, and probably is fine at it is.

Confirmed; I believe the related_name was changed on the ForeignKey from PowerFeed to Rack.

I am not sure what the Site.asn field was meant to be, because there also is a Site.asns: List[ASN] field; this one is probably also fine as it is.

Also confirmed.

@jeremystretch commented on GitHub (Oct 16, 2024): > While I found no matching issue for the Rack change, it looks like a renaming that happened as part of the engine switch, and probably is fine at it is. Confirmed; I believe the `related_name` was changed on the ForeignKey from PowerFeed to Rack. > I am not sure what the Site.asn field was meant to be, because there also is a Site.asns: List[ASN] field; this one is probably also fine as it is. Also confirmed.
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 severity: low 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#10357
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?