Netbox openapi schema is generating incorrect response types

[deathbeam]

Deployment Type

Self-hosted

NetBox Version

v3.7.3

Python Version

3.9

Steps to Reproduce

1. Check swagger for /api/dcim/sites
2. Create some dummy site with random ASN
3. Observe that swagger openapi schema tells that response for site.asns is supposed to be list of integers (e.g ids)
4. Observe that actual rest response for site.asns is the asns objects themselves

Expected Behavior

Openapi schema and actual API response must always match otherwise the schema is basically unusable. The response and schema used to match in past (confirmed on 3.4.5 at least) so something broke since.

Observed Behavior

Schema and response do not match. Observed behaviour is for site.asns, configcontext.roles, configcontext.tenants, virtualizationinterface.tagged_vlans, but there are probably more.

[deathbeam]

Is this really low severity? This breaks clients that use the openapi to generate/implement clients for netbox and its pretty big regression. We for example cannot upgrade to new Netbox without this feature working properly as we rely on openapi heavily.

[jeremystretch]

Yes, it's considered low severity as only the schema is affected; the function of the API itself is not.

Of course, if this is pressing for you, you are more then welcome to submit a PR for it. Can I assign this to you?

[deathbeam]

Yes, it's considered low severity as only the schema is affected; the function of the API itself is not.

Of course, if this is pressing for you, you are more then welcome to submit a PR for it. Can I assign this to you?

Alright. For now we are not upgrading past 3.5.0, if I will have some time I will look at it, but can't make any promises so probs dont assign it to me (in case someone that might know what caused this would want to look at this like @arthanson as I assume this PR caused the incorrect behavior: #11626)

[olekgo]

Interface.TaggedVlans is another one

[deathbeam]

Looks like this is now mostly resolved

EDIT:

But here is related issue that also needs to be solved for the schema to be correct: #16670