starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add better tests for GraphQL filtering and lookup #9407

New Issue
Open
opened 2025-12-29 20:49:24 +01:00 by adam · 10 comments
adam commented 2025-12-29 20:49:24 +01:00
Owner
Copy Link

Originally created by @arthanson on GitHub (Mar 28, 2024).

Proposed Changes

The GraphQL tests currently test all model fields, but are very light on testing any filtering of objects or sub-objects. We should add tests for checking different primary filters:

{
  site_list(filters: {name: {i_contains:"DM"}}) {
    id
    name
  }
}

and sub-object filtering:

{
  site_list {
    id
    name
    tags(filters: {name: {i_starts_with: "P"}}) {
      name
    }
  }
}

Justification

The filtering logic for Strawberry is undergoing some major refactors and we could easily miss issues with filtering without tests in-place.

Originally created by @arthanson on GitHub (Mar 28, 2024). ### Proposed Changes The GraphQL tests currently test all model fields, but are very light on testing any filtering of objects or sub-objects. We should add tests for checking different primary filters: ``` { site_list(filters: {name: {i_contains:"DM"}}) { id name } } ``` and sub-object filtering: ``` { site_list { id name tags(filters: {name: {i_starts_with: "P"}}) { name } } } ``` ### Justification The filtering logic for Strawberry is undergoing some major refactors and we could easily miss issues with filtering without tests in-place.
adam commented 2025-12-29 20:49:25 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 5, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 5, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:49:25 +01:00
Author
Owner
Copy Link

@loulecrivain commented on GitHub (Oct 23, 2024):

Heya, just a heads up from a Netbox-using organization regarding this proposed change.

I've seen and experienced some issues/regressions regarding GraphQL filters following latest release and refactors.
Now I know GraphQL isn't used much internally in Netbox itself. However for lots of people writing exporters, crawlers, you name it, GraphQL API is actually the go-to.

In my opinion, if we want to be on par with the level of quality of the REST API, ensuring filters are working as expected should be a priority. +1 for automated testing here

@loulecrivain commented on GitHub (Oct 23, 2024): Heya, just a heads up from a Netbox-using organization regarding this proposed change. I've seen and experienced some issues/regressions regarding GraphQL filters following latest release and refactors. Now I know GraphQL isn't used much internally in Netbox itself. However for lots of people writing exporters, crawlers, you name it, GraphQL API is actually the go-to. In my opinion, if we want to be on par with the level of quality of the REST API, ensuring filters are working as expected should be a priority. +1 for automated testing here
adam commented 2025-12-29 20:49:25 +01:00
Author
Owner
Copy Link

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

@loulecrivain thanks for your interest. Would you be willing to volunteer to contribute this work?

@jeremystretch commented on GitHub (Oct 23, 2024): @loulecrivain thanks for your interest. Would you be willing to volunteer to contribute this work?
adam commented 2025-12-29 20:49:25 +01:00
Author
Owner
Copy Link

@loulecrivain commented on GitHub (Oct 23, 2024):

@jeremystretch I get that the Netbox team may be busy right now with latest releases too. Unfortunately I currently do not really have the time to work on this, as I'm busy with other projects (and also not sure I'm familiar enough with Netbox codebase, as I haven't contributed lots).

So I'll have to politely decline 😉

@loulecrivain commented on GitHub (Oct 23, 2024): @jeremystretch I get that the Netbox team may be busy right now with latest releases too. Unfortunately I currently do not really have the time to work on this, as I'm busy with other projects (and also not sure I'm familiar enough with Netbox codebase, as I haven't contributed lots). So I'll have to politely decline :wink:
adam commented 2025-12-29 20:49:25 +01:00
Author
Owner
Copy Link

@loulecrivain commented on GitHub (Jan 29, 2025):

Commenting on this issue again, since we had another regression / breaking change in a minor release update (4.1.x -> 4.2.x).

#18433 broke in-production software depending on the GraphQL API. I'm going to be honest, I get the need for making the models evolve according to users needs, but why do so in a minor release?

I urge you to consider prioritizing better end-to-end tests for the GraphQL API. IMO if it's not as stable as the REST API, then there's no point in having this feature available for the users.

@loulecrivain commented on GitHub (Jan 29, 2025): Commenting on this issue again, since we had another regression / breaking change in a minor release update (4.1.x -> 4.2.x). #18433 broke in-production software depending on the GraphQL API. I'm going to be honest, I get the need for making the models evolve according to users needs, but why do so in a minor release? I urge you to consider prioritizing better end-to-end tests for the GraphQL API. IMO if it's not as stable as the REST API, then there's no point in having this feature available for the users.
adam commented 2025-12-29 20:49:26 +01:00
Author
Owner
Copy Link

@cnemo-cenic commented on GitHub (Oct 27, 2025):

Just adding that my employer pays for NetBox cloud and we recently saw breakage in a critical production service that depends on the graphql API due to a minor update.

@cnemo-cenic commented on GitHub (Oct 27, 2025): Just adding that my employer pays for NetBox cloud and we recently saw breakage in a critical production service that depends on the graphql API due to a minor update.
adam commented 2025-12-29 20:49:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 27, 2025):

@cnemo-cenic could you please link the bug report for reference?

@jeremystretch commented on GitHub (Oct 27, 2025): @cnemo-cenic could you please link the bug report for reference?
adam commented 2025-12-29 20:49:26 +01:00
Author
Owner
Copy Link

@cnemo-cenic commented on GitHub (Oct 27, 2025):

I don't have a bug report. You want me to create one in this repo?

@cnemo-cenic commented on GitHub (Oct 27, 2025): I don't have a bug report. You want me to create one in this repo?
adam commented 2025-12-29 20:49:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 27, 2025):

@cnemo-cenic it likely won't do much good now I'm afraid. If a bug report had been submitted soon after the release was made, we could have potentially shipped a fix to reverse any unexpected breaking changes.

In the absence of a bug report, could you share specifically what unexpected change(s) were made (and in what release) for consideration in the development of additional tests?

@jeremystretch commented on GitHub (Oct 27, 2025): @cnemo-cenic it likely won't do much good now I'm afraid. If a bug report had been submitted soon after the release was made, we could have potentially shipped a fix to reverse any unexpected breaking changes. In the absence of a bug report, could you share specifically what unexpected change(s) were made (and in what release) for consideration in the development of additional tests?
adam commented 2025-12-29 20:49:26 +01:00
Author
Owner
Copy Link

@cnemo-cenic commented on GitHub (Oct 27, 2025):

Yes we were specifically using a graphql query for ASNs:

query {
    asn_list(filters: {asn: $asn}) {
        asn
        [... other fields]
    }
}

The asn variable was a list of strings. That query broke with a message saying that [String!] did not match type IntegerLookup. The fixed query looked like this:

query {
    asn_list(filters: {asn: {filter_lookup: {exact: $asn}}}) {
        asn
        [... other fields (same as above)]
    }
}

With the asn variable now being a single integer (Int!).

We are currently running 4.3.7, I think we were likely using 4.2 but I'll double check with the team responsible for our NetBox cloud instance.

Edit: yes, we came from 4.2, perhaps 4.2.7 or 4.2.9

@cnemo-cenic commented on GitHub (Oct 27, 2025): Yes we were specifically using a graphql query for ASNs: ``` query { asn_list(filters: {asn: $asn}) { asn [... other fields] } } ``` The asn variable was a list of strings. That query broke with a message saying that `[String!]` did not match type `IntegerLookup`. The fixed query looked like this: ``` query { asn_list(filters: {asn: {filter_lookup: {exact: $asn}}}) { asn [... other fields (same as above)] } } ``` With the asn variable now being a single integer (`Int!`). We are currently running 4.3.7, I think we were likely using 4.2 but I'll double check with the team responsible for our NetBox cloud instance. Edit: yes, we came from 4.2, perhaps 4.2.7 or 4.2.9
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 netbox status: backlog topic: GraphQL topic: testing type: housekeeping
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#9407
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?