Nullable shorts are incorrectly mapped to int32 as opposed to Int32Value

[iress-ljm]

The schema generator and protobuf-net reflection service both seem to map short? decorated with the NullWrappedValue attribute to int32 when generating protobuf contracts, as opposed to Google's wrapper type google.protobuf.Int32Value. I'm aware that there isn't a supported field type for 16-bit integers, but we're generating our C# contracts based on metadata from a downstream API.

This was noticed when calling an API using the code first approach when referencing contracts generated by the schema generator. The API was treating a property with a type of int32 as an object when attempting to deserialise a request. This resulted in us seeing an exception thrown from within protobuf-net here.

See the below example for how the code-first request looks vs the generated proto file:

[ProtoContract]
[CompatibilityLevel(CompatibilityLevel.Level240)]
public class ExampleRequest 
{
    [ProtoMember(1, Name = "match_type")]
    [NullWrappedValue
    public short? MatchType { get; init; }
}

message ExampleRequest {
    int32 match_type = 1;
}

[mgravell]

Yep, that looks like a schema generation failure; I'll prioritize fixing this

[iress-ljm]

That's great, thank you @mgravell!