Updating Interface.tagged_vlans via API

[radek-senfeld]

Deployment Type

Self-hosted

NetBox Version

v3.7.5

Python Version

3.9

Steps to Reproduce

Choose any interface and retrieve it via the API.

>>> po21 = nb.dcim.interfaces.get(id=5048)
>>> po21.tagged_vlans = [5, 3, 39, 7, 8, 87, 85, 86, 37, 32, 36, 35, 9, 6, 10, 21, 26, 27, 23, 24, 22, 25, 28, 29, 16, 18, 17, 19, 20, 15, 14, 33]
>>> po21.updates()
{'tagged_vlans': [5, 3, 39, 7, 8, 87, 85, 86, 37, 32, 36, 35, 9, 6, 10, 21, 26, 27, 23, 24, 22, 25, 28, 29, 16, 18, 17, 19, 20, 15, 14, 33]}
>>> po21.save()
True

In this case Interface.tagged_vlans relation is saved without any problems.

The problem arises when you don't touch the tagged_vlans attribute, the client library detects no changes and the tagged_vlans is not sent to the server when PATCHing the object.

>>> po21 = nb.dcim.interfaces.get(id=5048)
>>> po21.description = po21.description + " "
>>> po21.updates()
{'description': 'Some description '}
>>> po21.save()
True

In this case the Interface.tagged_vlans relations are wiped out from the database.

Expected Behavior

Interface.tagged_vlans (and possibly any SerializedPKRelatedField) should hold the value until client sends e.g. empty list or None value. The missing attribute in PATCH call shouldn't cause resetting relations.

Observed Behavior

The relations have been annihilated.

[jeffgdotorg]

Thanks for reporting a suspected bug.

It appears you're using the pynetbox API library. To eliminate the possibility that a bug in pynetbox underlies this behavior, please try to reproduce the problem by operating the API directly using curl or the requests library.

[radek-senfeld]

Thanks for reporting a suspected bug.

It appears you're using the pynetbox API library. To eliminate the possibility that a bug in pynetbox underlies this behavior, please try to reproduce the problem by operating the API directly using curl or the requests library.

Yes, we're using pynetbox API library.

As formerly shown, the bug is not connected to the pynetbox library. It happens on the server side whenever the attribute "tagged_vlans" is missing from the PATCH request. Just give it a go, please..

As I stated, I'm pretty sure it could affect all other SerializedPKRelatedField fields in similar situation.

[radek-senfeld]

Tested via Requests. VLANs got nuked.

r = requests.patch("https://netbox.domain.tld/api/dcim/interfaces/69/", json={"description": "Patching just the description will vaporize VLANs"}, headers={"Authorization": "Token deadbeefbabe"})

[jeremystretch]

I was not able to reproduce this on v3.7.8. After assigning both tagged VLANs and an untagged VLAN to an interface, sending the following request did not change anything except its description (as intended):

curl -X PATCH \
-H "Authorization: Token $TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json; indent=4" \
http://netbox:8000/api/dcim/interfaces/1/ \
--data '{"description": "testing"}'

Please try upgrading to v3.7.8.

[radek-senfeld]

I was able to reproduce the issue on v3.7.8 using the curl command.

[jeremystretch]

@radek-senfeld then you'll need to provide more information about how someone else can reproduce the problem. As it stands, it appears to be an issue with your specific deployment or configuration.

[jeffgdotorg]

@radek-senfeld please try to keep in mind that every minute the maintainers spend fiddling with variables in an attempt to reproduce the behavior you're seeing is a minute that they're not working on another issue. The more specific and detailed you can be in your steps to reproduce, the quicker the team can validate the problem and get on with fixing it.

[MarianRychtecky]

Hi Jeff, this is Marian from Radek's team. We took some time to install a fresh instance of Netbox and test it on a new environment. Doing so will give us more details about where the problem could be. We tested the instance we use as a production clone and found the problem persistent. Now, we will test in a new instance and provide you with all the details.