ServiceStack losing string values when type is Dynamic

I’m using ServiceStack 5.1.0, RabbitMQ Server 3.7.5 and RabbitMQ Client 5.0.1

This is a basic test to test minimum functionality and used to work. The message is published with values but when ServiceStack picks it up all string values vanish. Numbers work fine. If Hello class is changed to public string Name it passes.

Any ideas?


public class Hello
    public dynamic Name { get; set; }
public class HelloResponse
    public string Result { get; set; }
public void Integration_RabbitMQ_BasicCheck()
    var mqServer = new RabbitMqServer();

    mqServer.RegisterHandler<Hello>(m =>
        new HelloResponse {Result = $"Hello, {m.GetBody().Name}!"});

    string result;
    using (var mqClient = mqServer.CreateMessageQueueClient())
        mqClient.Publish(new Hello {Name = "World"});

        var responseMsg = mqClient.Get<HelloResponse>(QueueNames<HelloResponse>.In);
        result = responseMsg.GetBody().Result;

    Assert.AreEqual("Hello, World!", result);

For some reason the code formatting messes up the line 1e4a461e1a53b2ea95c8720073b12151quot;

Should read
mqServer.RegisterHandler(m =>
new HelloResponse {Result = $“Hello, {m.GetBody().Name}!”});

Don’t use dynamic in DTOs, serializers have no idea what Type to serialize into. Use a string for properties that can be a number or an string.

A couple of questions:

What changed in functionality between the minor releases to break functionality that works in v5.0.2 and no longer works in v5.1.0?

I need to be able to send in a key value pair where the value is dynamic and not have it silently thrown away. RabbitMQ happily accepts the message so I would have expected ServiceStack to do the same - which was the case in v5.0.2

Is there a point I can intercept the request before this happens?

v5.1 is a major release like every other major ServiceStack release. dynamic is extremely fragile and has never been recommended with ServiceStack’s typed serializers, use a string if it contain numbers or strings, that way you can be guaranteed to know what type it is.

So my options are to remain on v5.0.2 or change the signature and rework.