Skip to content
This repository has been archived by the owner on Dec 23, 2024. It is now read-only.

fix: move inline enums to separate models for validation #91

Closed
wants to merge 4 commits into from

Conversation

ctreatma
Copy link
Contributor

A bit of a guess here, but I've noticed that even after upgrading openapi-generator in [email protected], the SDK is still unable to differentiate between VRF and VLAN virtual circuits. I suspect this is because the type values are not actually being validated against the enum definition when a virtual circuit model is deserialized.

We've observed similar behavior in other generated Equinix SDKs; in equinix-sdk-go we resolved the issue by configuring openapi-generator to create separate models for inline enums instead of generating inline enums inside their parent model. This enables the same option for metal-python.

Note that the generator identifies similar enums by looking at the supported enum values; as a result of this, the VrfVirtualCircuit uses a VrfIpReservationType enum as its type enum. The name mismatch is just an artifact of how the generator consolidates identical enums and does not impact runtime behavior.

@ctreatma
Copy link
Contributor Author

ctreatma commented Mar 14, 2024

Based on CI failures it looks like the generated enums are sent to the API as <enum_type>.<enum_value>:

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: HTTP response body: {"errors":["Invalid type specified in the types filter: findipreservationstypesparameterinner.public_ipv4. Valid types are: public_ipv4, private_ipv4, global_ipv4, public_ipv6, vrf"]}

We may be able to work around this with a custom template for enum models.

@ctreatma
Copy link
Contributor Author

Looks like the tests are passing in CI (the only failure I see is the inventory test, which is flaky) after the code was regenerated with the customized model_enum template

raise ValueError("must be one of enum values ('pending', 'waiting_on_peering_details', 'activating', 'changing_peering_details', 'deactivating', 'deleting', 'active', 'expired', 'activation_failed', 'changing_peering_details_failed', 'deactivation_failed', 'delete_failed')")
return value

@field_validator('type')
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to dig more into whether this @field_validator gets called by model_validate or not. Working on an example python script to reproduce the validation failure I'm running into with virtual circuits.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Welp, turns out the enum validation was working fine and I was getting errors from the virtual circuit module because I hadn't installed the newer metal-python in my virtualenv.

@ctreatma
Copy link
Contributor Author

This is not needed; enum validation appears to be working correctly without this change.

@ctreatma ctreatma closed this Mar 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant