Empty Message Custom Properties default to Boolean type

[spongessuck]

When resubmitting a single message, any Message Custom Properties that are blank default to Boolean type, but then I can't send the message with the blank value. After I change those fields to a different "nullable" type (I use String), I can send.

It'd be nice if it could default to a type that can be empty, or to allow any available type to be empty.

[SeanFeldman]

@spongessuck I'm not entirely sure how to go about this one. Custom properties are stored as a key value collection, where a value is one of the allowed types. If the value is null, I'd assume the value would be the default of the type. Boolean would be always false by default. A nullable version would be bool? but it would not be supported by Azure Service Bus when used for headers.

[spongessuck]

Here's what the properties look like in SBE:

You can see the 3 empty properties have been assigned the Boolean type. The values are null when sent to Azure Service Bus but it seems like SBE is defaulting them to the first type in the dropdown (Boolean) and I couldn't resubmit this message until I change the type selection on the null/empty-valued properties.

According to the article you linked, the type of the value is inferred, so as far as I can tell, there should be nothing in the message itself to suggest these properties have Boolean values. In fact, none of these properties are Boolean values even when they do happen to have one.

[SeanFeldman]

The original message that is resubmitted, was it already with those boolean headers w/o values?

[spongessuck]

No, the original message came from a c# client, and no values assigned to the properties dictionary were boolean types.

On Mon, Jun 6, 2022, 23:57 Sean Feldman @.***> wrote:

The original message that is resubmitted, was it already with those boolean headers w/o values?

— Reply to this email directly, view it on GitHub https://github.com/paolosalvatori/ServiceBusExplorer/issues/646#issuecomment-1148166616, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQTITU6Q3IZZJQYDIXKM23VN3CCFANCNFSM5VOKUVMA . You are receiving this because you were mentioned.Message ID: @.***>

[SeanFeldman]

Do you have the C# code that generated the message? I'd like to see what was it. Don't need the whole repro, just the snippet that has created the message and the ASB SDK version.

[spongessuck]

SDK is from NuGet package "Microsoft.Azure.ServiceBus" version 5.0.8 or 5.2.0, depending on the client app.

The code creating the message looks like this:

        protected Message ToServiceBusMessage(object message, TimeSpan? timeToLive = null)
        {
            var serviceBusMessage = new Message
            {
                Body = Encoding.UTF8.GetBytes(Newtonsoft.Json.JsonConvert.SerializeObject(message)),
                ContentType = "application/json",
            };

            if (timeToLive != null)
                serviceBusMessage.TimeToLive = timeToLive.Value;

            var type = message.GetType();
            ...

            this.messageMutator.MutateOutgoing(serviceBusMessage.UserProperties);

            return serviceBusMessage;
        }

MutateOutgoing copies values from a dictionary to the UserProperties dictionary of the message. The values come from a context object that produces the values you see in the screenshot of SBE I posted. None of these properties are boolean type; the ones that ends up set to Boolean in SBE is an int? that is set to null EDIT - ADD or strings set to null. When it has a value, the type in SBE is correctly set to an Int32 or String, it's only when it's null does it get set to Boolean.

[spongessuck]

It's also worth noting that this problem doesn't happen when selecting and resubmitting multiple messages - SBE passes those along without issue. It only happens when resubmitting a single message and the UserProperty value is null.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.