How should a server reject unknown union variants?

[david-perez]

Since 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:

https://github.com/awslabs/smithy/blob/1863d672dde488ccd81d9c00c64f57a26728f75d/smithy-aws-protocol-tests/model/restJson1/validation/malformed-enum.smithy#L17-L49

(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:

1. Immediately reject the request with a deserialization failure; or
2. 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.

[adamthom-amzn]

I agree the answer should be 1.

[mtdowling]

(1) would still be a 400 response in HTTP based protocols, right?

[adamthom-amzn]

yes, SerializationException is a 400

[david-perez]

I was wondering if the behavior for unknown enum variants has changed with IDL v2. In IDL v2, we have enum shapes instead of enum constraint traits, so presumably logic would dictate that they should now be handled like in the case of unknown union variants? That is a big behavioral change.

[mtdowling]

Hm, no, enums are still open types. There's effectively no behavioral change, just a modeling change.

[david-perez]

I'm guessing set shapes in IDL v1 should be rejected in the case of duplicate items in the same way as list shapes with uniqueItems in 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.

[mtdowling]

Looks like this is answered

[david-perez]

Do we have a protocol test establishing this behavior? I thought that was why the label was added.

[mtdowling]

Oh missed that. Pushed #2022