-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider not throwing exceptions when deserializing unknown enum values #90
Comments
I'd split those issues into two categories:
Do you know of a way to handle this more gracefully in Footnotes |
Having a dig around, it looks like the You can specify a fallback value on each enum using [PublicAPI]
[JsonConverter(typeof(JsonStringEnumMemberConverter))]
[JsonStringEnumMemberConverterOptions(deserializationFailureFallbackValue: -1)]
public enum HookType
{
[EnumMember(Value = "Repository")]
Repository,
[EnumMember(Value = "Organization")]
Organization,
[EnumMember(Value = "App")]
App,
} Another way is to create a derived [PublicAPI]
[JsonConverter(typeof(JsonStringEnumMemberConverterWithFallback))]
public enum HookType
{
[EnumMember(Value = "Repository")]
Repository,
[EnumMember(Value = "Organization")]
Organization,
[EnumMember(Value = "App")]
App,
}
public sealed class JsonStringEnumMemberConverterWithFallback : JsonStringEnumMemberConverter
{
private static readonly JsonStringEnumMemberConverterOptions Options = new()
{
DeserializationFailureFallbackValue = -1,
};
public JsonStringEnumMemberConverterWithFallback()
: base(Options)
{
}
} Given that, one approach could be to use a custom implementation of it that uses -1 to signify an invalid value, then unknown values would only affect code that tried to use something that was affected. It would stop the serializer failing, but anything reading the specific webhook event property that received that invalid value would do whatever the user code does with it. The upside to that is the user's code doesn't use a given event property, the changes remain invisible to them. The downside is that the user's code might not handle an undefined value in a nice way if it's started to run once it's been deserialized. Another approach entirely (but a big breaking change) could be to type enums like octokit.net does by wrapping them with the Option 1 seems more light-touch, but isn't really customisable. Option 2 is more flexible for users, but would likely need code fix-ups to adopt in an existing application due to the binary-breaking changes. |
I think that option 1 would be good for a short-term fix. We can do that in a What do you think? |
That sounds reasonable to me. I'll have a test of approach 1 and see how it handles things. If it looks viable I'll push up a draft PR for you to take a look at. |
Add fallback value for unknown enumeration values. Relates to octokit#90.
I've started working on option 2 in the |
- Add an `Unknown` value to the `ReviewState` enum as it wasn't accounted for in octokit#90 before it was merged. - Add unit tests to catch future missing `Unknown` values.
- Add an `Unknown` value to the `ReviewState` enum as it wasn't accounted for in #90 before it was merged. - Add unit tests to catch future missing `Unknown` values.
Describe the feature
There have been a number of times where drift between the schema definitions and/or this library and the actual runtime behaviour of github.com/GitHub Enterprise Server cause runtime failures in applications consuming the library to process webhooks. Examples include #52, #76 and #89.
To make consuming applications more resilient to natural evolution of the service over time, it would be preferable if enum deserialization is more tolerant to undefined values (this could be opt-in).
This is particularly impactful with github.com as the payloads could change at any time without advance notice to the owner of an integration due to a new deployment/feature on the server. In contrast, upgrades to GitHub Enterprise Server are more predictable and can be planned for in advance as the appliance is typically upgraded through a specific decision on the part of its operators.
The text was updated successfully, but these errors were encountered: