No generated enum has an unknown-variant fallback, so one new server enum value breaks deserialization of the whole response
Context: API Makeathon participant. Found while reviewing the generated types; independently confirmed by a second review pass.
The enum generator emits closed serde enums with one variant per known schema value and no #[serde(other)], string-backed catch-all, or custom unknown-value handling (kittycad/src/types.rs; generator at openapitor/src/types/mod.rs). Variants named Unknown exist only where the API schema specifies them; they are not generic fallbacks.
These clients pin a moving API. When the server adds one enum value (which this API does routinely for file formats, ML endpoints, providers, and units), deserialization of the entire containing response fails with a serde error in every already-shipped client binary, even when the caller does not use that field. The Go client is immune because its "enums" are plain string types.
Concrete failure
Zoo adds a new AccountProvider (returned as Vec<AccountProvider>) or a new ApiCallStatus. A shipped kittycad.rs binary calling users().list(...) starts erroring for every existing user whose account contains one such record, with no workaround short of upgrading the crate. Known entries in the same response become inaccessible.
Verify
serde_json::from_str::<Vec<AccountProvider>>(r#"["github","future_provider"]"#)
returns an error instead of preserving github and representing the new value.
Suggested fix
Have the generator emit a catch-all variant (#[serde(other)] Unknown, or a string-backed Other(String)) on generated enums, so an additive server value degrades gracefully instead of failing the whole response.
Environment
Reviewed against the current main of KittyCAD/kittycad.rs.
No generated enum has an unknown-variant fallback, so one new server enum value breaks deserialization of the whole response
Context: API Makeathon participant. Found while reviewing the generated types; independently confirmed by a second review pass.
The enum generator emits closed serde enums with one variant per known schema value and no
#[serde(other)], string-backed catch-all, or custom unknown-value handling (kittycad/src/types.rs; generator atopenapitor/src/types/mod.rs). Variants namedUnknownexist only where the API schema specifies them; they are not generic fallbacks.These clients pin a moving API. When the server adds one enum value (which this API does routinely for file formats, ML endpoints, providers, and units), deserialization of the entire containing response fails with a serde error in every already-shipped client binary, even when the caller does not use that field. The Go client is immune because its "enums" are plain string types.
Concrete failure
Zoo adds a new
AccountProvider(returned asVec<AccountProvider>) or a newApiCallStatus. A shipped kittycad.rs binary callingusers().list(...)starts erroring for every existing user whose account contains one such record, with no workaround short of upgrading the crate. Known entries in the same response become inaccessible.Verify
returns an error instead of preserving
githuband representing the new value.Suggested fix
Have the generator emit a catch-all variant (
#[serde(other)] Unknown, or a string-backedOther(String)) on generated enums, so an additive server value degrades gracefully instead of failing the whole response.Environment
Reviewed against the current
mainof KittyCAD/kittycad.rs.