Better handling of unknown enums

[abhinav]

Because thriftrw-node exposes enums as strings, it doesn't have any way of handling unknown enums.

In other languages, since it's exposed as an integer, there's no parse error and you can have a catch-all for unrecognized cases:

if value == MyEnum.SomeItem:
    # ...
elif value == MyEnum.AnotherItem:
    # ...
else:
    # catch-all

We need thriftrw-node to have some way of dealing with unrecognized enums. One
possibility is to expose the received integer as-is in the unrecognized item
case.

if (value === 'SomeItem') {
    // ...
} else if (value == 'AnotherItem') {
    // ...
} else {
    console.log("Received item " + value);
}

[abhinav]

CC @kriskowal @blampe @breerly

[kriskowal]

It may be reasonable to surface an unrecognized enum as the underlying number. That would mean that an enum would be reified as either number or string, the latter if it is recognized.

I’m leery of folks switching on the number instead of the updating the IDL and using a name. We could alternately surface all unrecognized values as null.

[kriskowal]

Would it make sense to distinguish optional enum from required enum for purposes of validating enums in either the request or response context?

[abhinav]

I don't think we should differentiate between required and optional enums.

The idea behind exposing the number in the unrecognized case is not to let
people switch on that. It's for users to be able to switch on "Do I know how
to handle this?" We want them to be able to act on up to N different enum
items they do recognize, and have a consistent way of failing or handling the
cases that they don't recognize.

[Raynos]

We should at the very least return some special string like "thriftrw-node: unknown enum value from future" to get forwards compatibility working in some fashion instead of getting a "Cannot read thrift response" exception in the client.

A cannot read thrift response should only happen for "truly" breaking changes or malformed binary payloads.