Closed ctreatma closed 1 year ago
In terms of data quality, I think the values we're seeing for drive type and nic type indicate that 2 long-term fixes are needed:
NVMe
and NVME
exist as drive types indicates a lack of input validation and/or data normalization in the API; if the spec says NVME
then NVMe
should be rejected as an input, or at least the API should convert the drive type to uppercase in response JSONdrives: []
) or omit the field entirelyBye, enums 😢 (I wonder if Redoc x-
extensions offer a way to list the likely values)
This PR is included in version 0.22.2 :tada:
The previous fix for plan drive type did not work; it turns out that the API plan data includes plans with drive type
NVMe
and plans with drive typeNVME
. As mentioned on the previous PR, adding both options to the enum generates invalid code, and we don't have a practical way to enable case-insensitive comparisons for string enums.Reverting the plan drive type to a plain string uncovered a different issue with the nic type enum: some plans (
storage
type, possibly others) include the following for drives and nics:Rather than test
nullable: true
here, I opted to change the nic type to a plain string as well.