Skip to content
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

Missing GraphQL fields #17749

Closed
corubba opened this issue Oct 12, 2024 · 2 comments · Fixed by #17765
Closed

Missing GraphQL fields #17749

corubba opened this issue Oct 12, 2024 · 2 comments · Fixed by #17765
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@corubba
Copy link
Contributor

corubba commented Oct 12, 2024

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.

@corubba corubba added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Oct 12, 2024
@arthanson arthanson added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: needs triage This issue is awaiting triage by a maintainer labels Oct 15, 2024
@jeremystretch jeremystretch 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 Oct 15, 2024
@jeremystretch
Copy link
Member

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

@jeremystretch
Copy link
Member

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 up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available 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