search

The-Nazara-Project / Nazara

A CLI application to create and update machines and VMs in Netbox.
GNU General Public License v3.0
11 stars 2 forks source link

[TASK] Handle unsanitary NetBox response parameters #75

Open ByteOtter opened 2 months ago

ByteOtter commented 2 months ago

After further investigation, the erroneously null fields in NetBox's responses to the Interface endpoints definitely looks like this is a problem on NetBox's end.

Looking at the fields link_peers_type and connected_endpoints in the Interface struct, we can see that the schema requires them to be a String and a Vec. Which gets translated correctly in thanix_client. However, the application returns both of these values as null, which does not correspond with the schema.

This leads to several conclusions:

  1. This could a problem that can re-occur in more fields than the ones we encountered here.
  2. A temporary workaround is required to allow v0.1.0 to be working with NetBox v3.6.x as per the decision made in #74.
  3. An automated integration test suite is required to catch these errors correctly.

Backend bug hunting must also be conducted as we cannot be sure this problem is fixed with NetBox v4.x. I had opened an issue with NetBox about a possible bug on this end (https://github.com/netbox-community/netbox/issues/16301) they asserted that this is not an issue with them. We need to collect further information before we can proceed to report a bug again.

Originally posted by @ByteOtter in https://github.com/The-Nazara-Project/Nazara/issues/73#issuecomment-2326581393

ByteOtter commented 2 months ago

This has been addressed somewhat by implementing a workaround when generating API clients with Thanix. See https://github.com/The-Nazara-Project/Thanix/commit/7c54106807f78cfeb513635679209c1032c91a04 for more info.

The issue will stay open for now to remind us to address this again in the future.

Also, further research needs to be done on NetBox's end whether this may be an issue with their database migration problem.