How should a server reject unknown union variants?
See original GitHub issueSince enum is a constraint trait, if a server encounters an unknown enum variant, it should reject the request just like it would fail to constrain any other value for a constrained shape: that is, the server should parse the request successfully and then constrain the resulting value, returning a collection of constraint violations, if any. In the case of an unknown enum variant, one of those errors should convey that there was an unknown enum variant. Here is one protocol test in the validation suite enforcing this behavior:
(Aside: it would be nice if the spec on constraint traits documented this server behavior instead of using the protocol tests as a normative reference).
My question is what should happen if a server encounters unknown union variants. It is not obvious, since a union is a shape itself and not a constraint trait like enum. If a server is parsing a union, it will first read the tag and match it against the known modeled tags. If it encounters an unknown tag, should it then:
- Immediately reject the request with a deserialization failure; or
- Store the unknown tag, discard the union’s value (since it can’t know its structure), parse the rest of the request successfuly, and insert some sort of validation error in the response, just like we should do for constraint traits?
I think the answer should be (1); it’d be nice if a test could be added to malformed-union.smithy and the spec could call this out if so.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (6 by maintainers)

Top Related StackOverflow Question
Hm, no, enums are still open types. There’s effectively no behavioral change, just a modeling change.
I’m guessing
setshapes in IDL v1 should be rejected in the case of duplicate items in the same way aslistshapes withuniqueItemsin IDL v2 then: the request is parsed entirely and only then the check is performed. So, another modeling change, but no behavioral change in this regard.