outgoing mqtt connections fail to publish messages when tracing is enabled

[JeffreyThijs]

If we enable open tracing on the ditto services, active outgoing mqtt connections (other types might have this problem as well) fail to publish their messages due to failing to transform ExternalMessage to GenericMqttPublish due to a blank tracestate header in the ExternalMessage headers.

The following error is thrown:

Ran into a failure when publishing signal: Failed to send message: 
Failed to transform ExternalMessage to GenericMqttPublish: The value 
must not be blank. Sending the message to an external system failed, 
please check if your connection is configured properly and the target 
system is available and consuming messages. - Message headers: 
[content-type=application/vnd.eclipse.ditto+json, tracestate=, 
context-tags=upstream.name=ditto-connectivity;, 
traceparent=00-3f0f66b556dc61e2250e5355bb33f83a-142e83f65527125d-01, 
correlation-id=782a32b1-4660-462d-8ac7-51d865bc3d0c] 

Is this expected behavior? If so, why is it required that the headers are blank? It is a bit silly that this requirement completely disrupts the publication of messages.

[thjaeckle]

This is surely not the expected behavior. Looks like a bug to me.

The error message seems to come from:

ditto/connectivity/service/src/main/java/org/eclipse/ditto/connectivity/service/messaging/mqtt/hivemq/message/publish/UserProperty.java

Lines 41 to 45 in 21f1b0d

	private static String assertNeitherNullNorBlank(final String s, final String argumentName) {
	return ConditionChecker.checkArgument(ConditionChecker.checkNotNull(s, argumentName),
	a -> !a.isBlank(),
	() -> MessageFormat.format("The {0} must not be blank.", argumentName));
	}

Invoked here trying to map all external headers to MQTT5 user properties:

ditto/connectivity/service/src/main/java/org/eclipse/ditto/connectivity/service/messaging/mqtt/hivemq/publishing/ExternalMessageToMqttPublishTransformer.java

Line 251 in 21f1b0d

return new UserProperty(headerKey, headerValue);

So this only affects MQTT5 connections.
Non-existant (null) values should probably just be ignored ..

@jufickel-b could you have a look?

*edit: had another look and adjusted the potential source of the error to MQTT5 user property mapping

[thjaeckle]

@JeffreyThijs if this is urgent to you, I suggest you propose a PR fixing the issue.
As tracing is currently not in use by the Bosch team, this probably won't get high priority.

[JeffreyThijs]

@thjaeckle, ok thanks for the clarification. I'll try to provide a PR to fix this problem. However, we encountered this problem with mqtt3 sessions though.

[thjaeckle]

Fixed via #1565