0

I am sending a message from a device to Azure IoT Hub with a set route to forward all device messages to Azure Service Bus. I noticed a bug where every first bokered msg Id on service bus is null. The following messages are fine with a valid msg Id.

Device code:

        var messageString = JsonConvert.SerializeObject("json msg");
        var message = new Message(Encoding.ASCII.GetBytes(messageString));
        _deviceClient = DeviceClient.Create(IotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey(DeviceId, DeviceKey), TransportType.Amqp);
        await _deviceClient.SendEventAsync(message);

I suspect it is an issue in IoT side as testing without IoT (sending directly) works well. enter image description here

Any troubleshooting ideas?

This seems to be related: AMQP Message Null when using Azure IoTHub Routing

Rotem Varon
  • 1,597
  • 1
  • 15
  • 32

1 Answers1

2

your device should be populated a message id, for instance:

message.MessageId = "your message id";
Roman Kiss
  • 7,925
  • 1
  • 8
  • 21
  • tnx for your comment. I will give it a try. I wonder If I should populate msg Id, why is the Id of rest of the msgs that follows have an Id automatically? see pic. – Rotem Varon Apr 05 '18 at 21:24
  • Based on the routes to the default endpoint (events), the EventData messages in the Event Hub are not populated for message-id in the Azure IoT Hub. It should be done by sender such as a device. So, back to the BrokeredMessage. It looks like the first message (in your picture) is correct when its value is null and this value should be stayed null for other messages until the sender (device) did a change. – Roman Kiss Apr 05 '18 at 22:37
  • setting the msg Id sloves it (or better said, workaround it). The problem is when u send msg from the device to IoT Hub, u create a Microsoft.Azure.Devices.Client.Message which does not force u to set the Id (not in the constructor), so I assumed it is set auto. and it is as for the 2nd msg... I think that should be fixed by MS. – Rotem Varon Apr 05 '18 at 22:59
  • the message system properties such as correlationId, messageId, to, ContentType and ContentEncoding are full transparent to the Azure IoT Hub. In other words, the device (sender) has a responsibility to populate them. For instance, device with a mqtt direct protocol will add it to the topic (&$.mid=myMessageId), or using the REST API via a header (iothub-messageId=myMessageId) – Roman Kiss Apr 05 '18 at 23:34
  • tnx. that great insights. I wonder if that explains why the msg Id is being set only from the 2nd msg sent? out of the blue... even though I did not set it at all – Rotem Varon Apr 05 '18 at 23:51
  • 1
    it looks like having a messageId from the 2nd message up is a bug. You can verify very easy using an Azure EventHubTrigger function to consume messages on the events endpoint. The message-id property from the systemproperties doesn't exist it (because it is null). – Roman Kiss Apr 06 '18 at 00:01