Message properties are not being sent in GRPC payload to out of process worker due to bug in RabbitMQ.Client 5.1.2

[kshyju]

When a producer sends a message with message properties, it is not being sent to the out-of-process worker, instead the type name string is being sent.

Version: WebJobs.Extensions.RabbitMQ version 1.1.0

Note: This is not a code bug in the rabbitmq-extension, but a bug in the RabbitMQ.Client version 5.1.2, which we are using for WebJobs.Extensions.RabbitMQ 1.1.0

Repro steps

1. Create a dotnet isolated worker to be used as a consumer of the message.
2. Publish a message with any properties other than reply_to. You may use the RabbitMQ admin portal to do this.
3. In the dotnet consumer project, setup a break point. Inspect the binding data on function context for BasicProperties. You can see that the value is a string of the type name (RabbitMQ.Client.Framing.BasicProperties) instead of a complex object.

Why is this happening ?

I did a bit of investigation on why this is happening. Apparently, the host is trying to serialize the BasicProperties object while trying to create the GRPC payload to send to the worker, but it throws because accessing the ReplyToAddress property on BasicProperties object is throwing an exception. When an exception happens while trying to serialize the object, we call the ToString on the object in the catch block. In our case, the ToString call on this type is producing the type name value string.

The WebJobs.Extensions.RabbitMQ version 1.1.0 is using RabbitMQ.Client 5.1.2 package. If you look at the ReplyToAddress property implementation on 5.1.2, it is returning the result of PublicationAddress.Parse(this.ReplyTo).

The PublicationAddress.Parse method is internally calling the Regex.Match method and passing the reply_to property value. This method will throw an ArgumentNullException when the input is null, which is what is happening in our case.

Mitigation

We will advise the users to always specify the reply_to property when publishing a message.

Fix

The RabbitMQ team had fixed this issue in May 2020. The fix is published in their 6.1.0 release. We should publish a new version of WebJobs.Extensions.RabbitMQ consuming the 6.1.0 RabbitMQ.Client package.

[kshyju]

cc @pragnagopa @yojagad

[pragnagopa]

cc @JatinSanghvi @lpapudippu

[kshyju]

@JatinSanghvi Any update on the progress of this fix?

[JatinSanghvi]

@JatinSanghvi Any update on the progress of this fix?

@kshyju, was busy with other tasks. I will work on this one with priority starting 11/18.

[JatinSanghvi]

Verified that for out-of-proc Function app,:

context.BindingContext.BindingData.TryGetValue("BasicProperties", out var basicProperties); outputs:

• RabbitMQ.Client.Framing.BasicProperties without fix.
• {"ContentType":null,"ContentEncoding":null,"Headers":{"hname":"aHZhbHVl"},"DeliveryMode":1,"Priority":0,"CorrelationId":null,"ReplyTo":null,"Expiration":null,"MessageId":null,"Timestamp":{"UnixTime":0},"Type":null,"UserId":null,"AppId":null,"ClusterId":null,"ProtocolClassId":60,"ProtocolClassName":"basic","Persistent":false,"ReplyToAddress":null} with fix in place.