deserializing nullable value types

[d-moos]

Hey,

I'm using ServiceStack.Text 6.5.0, C#10 and Enabled nullable reference types

I'm curious if I've missed a JsConfig settings or if I miss something else.

I have the following record

public record Foo(ObjectId? NextCursor, ulong? MyValue, string? MyString);

where ObjectId is a readonly struct:

public struct ObjectId
{
    private readonly string _objectId;

    public ObjectId(string objectId)
    {
        _objectId = objectId;
    }

    public override string ToString() => _objectId;

    public static implicit operator ObjectId(string objectId) => new(objectId);
    public static implicit operator string(ObjectId objectId) => objectId._objectId;
}

Deserializing var json ="{\"myValue\": null, \"myString\": null}"; results in the expected instance where NextCursor is null.
However if the field is available (but marked with null) var json ="{\"nextCursor\": null, \"myValue\": null, \"myString\": null}"; the NextCursor property has a value.
I would expect it to still be null - is that a configuration that I missed? It works for the ulong? and string? example just fine.

Best,
Daniel

[d-moos]

Testcase:

public record Foo(ObjectId? NextCursor, ulong? MyValue, string? MyString);
    
    [Test]
    public void ObjectId()
    {
        var json ="{\"nextCursor\": null, \"myValue\": null, \"myString\": null}";


        var newtonFoo = Newtonsoft.Json.JsonSerializer.Create().Deserialize<Foo>(new JsonTextReader(new StringReader(json)));
        var serviceStackFoo = json.FromJson<Foo>();

        Assert.That(!newtonFoo.NextCursor.HasValue);
        Assert.That(!serviceStackFoo.NextCursor.HasValue);
    }

The NewtonSoft example works as intended.

[mythz]

Structs have scalar behavior in ServiceStack.Text, if you want DTO behavior it needs to be changed to a class or extend it to support Custom Serialization.

But I'll test this behavior to see if it can be changed.

[d-moos]

Chaning ObjectId to a class doesn't solve the issue - it's still not null (Assert.That(serviceStackFoo.NextCursor == null); fails).
The root-cause is most likely that the deserializer calls the constructor for ObjectId with an empty-string (even if nextCursor is null).

[mythz]

We can't use records with init only auto property setters in our test project, but if I expand the struct with explicit properties this test passes:

[Test]
public void Does_deserialize_ObjectId()
{
    var json ="{\"nextCursor\": null, \"myValue\": null, \"myString\": null}";
    var foo = json.FromJson<RecordObjectId>();
    Assert.That(!foo.NextCursor.HasValue);
}

public record RecordObjectId(ObjectId? NextCursor, ulong? MyValue, string MyString)
{
    public ObjectId? NextCursor { get; } = NextCursor;
    public ulong? MyValue { get; } = MyValue;
    public string MyString { get; } = MyString;
}

Can you try changing the struct impl to see if it makes a difference?

[d-moos]

The example above fails however for tests where nextCursor actually has a value:

public class StructSerializationTests
{
    public record Foo(ObjectId? NextCursor, ulong? MyValue, string? MyString)
    {
        public ObjectId? NextCursor { get; } = NextCursor;
        public ulong? MyValue { get; } = MyValue;
        public string? MyString { get; } = MyString;
    };

    [Test]
    public void ObjectId_With_Value()
    {
        var json ="{\"nextCursor\": \"hasValue\", \"myValue\": null, \"myString\": null}";

        var serviceStackFoo = json.FromJson<Foo>();
        Assert.That(serviceStackFoo.NextCursor.HasValue);
    }
    
    [Test]
    public void ObjectId_With_NULL_Value()
    {
        var json ="{\"nextCursor\": null, \"myValue\": null, \"myString\": null}";

        var serviceStackFoo = json.FromJson<Foo>();
        Assert.That(!serviceStackFoo.NextCursor.HasValue);
    }
    
        
    [Test]
    public void ObjectId_Without_Value()
    {
        var json ="{\"myValue\": null, \"myString\": null}";

        var serviceStackFoo = json.FromJson<Foo>();
        Assert.That(!serviceStackFoo.NextCursor.HasValue);
    }
}

[mythz]

This should now be resolved from this commit this change is available from v6.5.1+ that's now available on MyGet.

[d-moos]

working like a charm.
thanks for the quick patch !