Repository navigation
openapi: a promotion mapping can't say which extension values state the fact #654
Description
Problem
Extensions that state openness often do it with a value: allow or disallow, true or false, or a small vocabulary. extensionOpenness (compilers/openapi/internal/lowering/promotion.go:235) treats any value that isn't a boolean as "open":
openapi.Options{Promotions: openapi.ExtensionPromotions{Targets: map[string]openapi.ExtensionTarget{
"x-unknown-values": openapi.TargetEnumOpen,
}}}Status: {type: string, enum: [a, b], x-unknown-values: disallow}Status compiles to closed: false with inferred: extension-promotion: the document said the opposite. A caller has no way to state which values mean open, and nothing reports a value the mapping doesn't understand.
Proposal
Let a mapping entry name the values that state the fact, for example {target: enum.open, when: [allow]}, and report any other value instead of reading it. The rule of docs/compilers/openapi.md#extension-promotion that a value the field can't hold is reported and not coerced then covers these keys too.
Activity
docs: state each limit of a promotion where it lives
OmarAlJarrah commentedon Nov 1, 2026
#1229 adds an instance on another target.
TargetDeprecationtakes the textdeprecatedor a booleantrue, which is right for a key meaning only that, and the two stability keys are read as sources of it for their worddeprecated. A mapping cannot narrow a source to that word, sox-stability: truecreates aDeprecation, markedextension-promotion, with nothing reported, where the document likely means something else.The value set this issue proposes would settle it. The golden spec writes no boolean under either key:
x-stabilityisbeta280 times andstabletwice (spec @319dc756).docs/compilers/openapi.md#extension-promotionnames this in its Status.