interfaces type get from Graphql is different from that get from dcim.interfaces.type.value #6160

New Issue

adam · 2025-12-29T19:37:27+01:00

adam commented

2025-12-29 19:37:27 +01:00

Originally created by @YukiYue on GitHub (Mar 3, 2022).

NetBox version

v3.0.8

Python version

3.8

Steps to Reproduce

query interfaces type using graphql:

query {
  device_list(name:"xxx"){
    interfaces{
      type
    }
  }

result would be DcimInterfaceTypeChoices, which is like:

VIRTUAL
LAG
A_100BASE_TX
A_1000BASE_T
A_2_5GBASE_T
A_5GBASE_T
A_10GBASE_T

if using pynetbox to get resource: dcim.interfaces.type.value, the return result is like 10gbase-t, 100gbase-t......

I'm curious why making these 2 different, and if there's way to get type result like '10gbase-t' using Graphql.

Expected Behavior

interface type get from Graphql should be the same as that get from dcim.interfaces.type.value

Observed Behavior

Inconsistency between the 2 occurred.

Originally created by @YukiYue on GitHub (Mar 3, 2022). ### NetBox version v3.0.8 ### Python version 3.8 ### Steps to Reproduce 1. query interfaces type using graphql: ``` query { device_list(name:"xxx"){ interfaces{ type } } ``` result would be DcimInterfaceTypeChoices, which is like: ``` VIRTUAL LAG A_100BASE_TX A_1000BASE_T A_2_5GBASE_T A_5GBASE_T A_10GBASE_T ``` 2. if using pynetbox to get resource: dcim.interfaces.type.value, the return result is like 10gbase-t, 100gbase-t...... I'm curious why making these 2 different, and if there's way to get type result like '10gbase-t' using Graphql. ### Expected Behavior interface type get from Graphql should be the same as that get from dcim.interfaces.type.value ### Observed Behavior Inconsistency between the 2 occurred.

adam closed this issue

2025-12-29 19:37:27 +01:00

adam commented

2025-12-29 19:37:28 +01:00

@jeremystretch commented on GitHub (Mar 3, 2022):

Inconsistency between the 2 occurred.

Consistency between the two was never a design goal: they are two completely independent APIs. Additionally, this behavior has been in place since the implementation of the GraphQL API in v3.0.

If you'd like to propose the way static choices are reported by the GraphQL API, please resubmit this as a feature request citing your specific use case as well as justification for the breaking change.

@jeremystretch commented on GitHub (Mar 3, 2022): > Inconsistency between the 2 occurred. Consistency between the two was never a design goal: they are two completely independent APIs. Additionally, this behavior has been in place since the implementation of the GraphQL API in v3.0. If you'd like to propose the way static choices are reported by the GraphQL API, please resubmit this as a feature request citing your specific use case as well as justification for the breaking change.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6160