While working on a Sputnik satellite I ran into an inconsistency in how nested structs get serialized in typed query results, depending on the container.
An Option<Struct> field comes out camelCase on the JSON side, while a Vec<Struct> of the same record comes out snake_case. So you end up keeping two schemas for the same type, and switching an endpoint between opt and vec can fail at runtime with something like:
Error converting from js 'JsonData' into type 'Candid': missing field 'inviteCode'
From what I could tell it comes from functions-tools/src/converters/zod-to-rust.ts, where the vec case sets needsJsonData: false while opt passes through inner.needsJsonData, so array element structs don't get the #[json_data(nested)] attribute.
Flipping just that isn't enough though, the JsonData derive macro in junobuild/juno (derive.rs) doesn't seem to handle a nested Vec yet (nested_json_data_ident only recurses into Option).
Making vec camelCase would be breaking, so it might need to be opt-in or a major.
While working on a Sputnik satellite I ran into an inconsistency in how nested structs get serialized in typed query results, depending on the container.
An
Option<Struct>field comes out camelCase on the JSON side, while aVec<Struct>of the same record comes out snake_case. So you end up keeping two schemas for the same type, and switching an endpoint betweenoptandveccan fail at runtime with something like:From what I could tell it comes from
functions-tools/src/converters/zod-to-rust.ts, where theveccase setsneedsJsonData: falsewhileoptpasses throughinner.needsJsonData, so array element structs don't get the#[json_data(nested)]attribute.Flipping just that isn't enough though, the
JsonDataderive macro injunobuild/juno(derive.rs) doesn't seem to handle a nestedVecyet (nested_json_data_identonly recurses intoOption).Making
veccamelCase would be breaking, so it might need to be opt-in or a major.