Repository navigation
openapi: decide whether an extension mapping with non-string keys is kept with its keys stringified #617
Description
Problem
A vendor extension whose value is a YAML mapping with integer or boolean keys, a common shape for naming the members of an integer enum, is dropped whole:
Level:
type: integer
enum: [1, 2]
x-member-names: {1: Low, 2: High}warning openapi/degraded-construct …: extension "x-member-names" could not be serialized
This is deliberate today: compilers/openapi/unpreservable_test.go lists a non-string key as one of the two reachable ways a preserved payload fails to convert. The consequence is that Unmodeled's losslessness depends on the key type, for a construct that is plain, valid YAML.
Options
- Keep the drop, as today.
- Stringify scalar keys when converting to JSON (
1→"1"), and record that the conversion happened, so a consumer that cares can tell.
Related: #245.
Activity
OmarAlJarrah commentedon Oct 23, 2026
#1106 decides this for the second option, without a marker. A scalar key is kept as the text it spells (
{"1": "Low", "2": "High"}), in an extension and in every other verbatim payload.No marker records a conversion because, under the specification's reading, none happens: the Format section limits a key used in a YAML map to a scalar string as the YAML Failsafe schema defines it, and under that schema
1is the string"1". The parser reads every key that way too. A key that is no scalar, a mapping or a list written as a key, is another matter: the parser reads it as the empty string, so the compiler does the same and reports the key as an error (openapi/validation/validation-type-mismatch).The rule is
verbatim-preservationonce #1106 lands.