'Zero' values are not shown by gz topic -e

[jrutgeer]

This is rather strange:

Execute in one terminal:

gz topic -e -t /foo

Execute in another terminal:

gz topic -t /foo -m gz.msgs.Int32 -p 'data:10'
gz topic -t /foo -m gz.msgs.Int32 -p 'data:0'
gz topic -t /foo -m gz.msgs.Float -p 'data:0.5'
gz topic -t /foo -m gz.msgs.Float -p 'data:0.0'
gz topic -t /foo -m gz.msgs.Float -p 'data:0.1'

Expected output:

data: 10

data: 0

data: 0.5

data: 0.0

data: 0.1

Actual output:

data: 10

data: 0.5

data: 0.1

So there is an extra line feed, but no data for 'zero' values.

This is for both the default and the json output.

Relevant code part:

gz-transport/src/cmd/gz.cc

Lines 265 to 280 in c31134a

	std::function<void(const ProtoMsg&)> cb = [&](const ProtoMsg &_msg)
	{
	std::lock_guard<std::mutex> lock(mutex);
	switch (_outputFormat)
	{
	case MsgOutputFormat::kDefault:
	case MsgOutputFormat::kDebugString:
	std::cout << _msg.DebugString() << std::endl;
	break;
	case MsgOutputFormat::kJSON:
	{
	std::string jsonStr;
	google::protobuf::util::MessageToJsonString(_msg, &jsonStr);
	std::cout << jsonStr << std::endl;
	}
	break;

I assume it must be an oddity of the protobuf message?

gz-transport/include/gz/transport/TransportTypes.hh

Line 71 in c31134a

using ProtoMsg = google::protobuf::Message;

[azeey]

Looks like there might be an option to tell Protobuf to include default value fields for the JSON ouptut https://stackoverflow.com/questions/31021797/protobuf-doesnt-serialize-default-values and https://protobuf.dev/reference/cpp/api-docs/google.protobuf.util.json_util/#JsonPrintOptions. Would you be up for submitting a PR?

I'm afraid it's not trivial to do the same for DebugString.

[jrutgeer]

@azeey My main reason to report the issue was just to make sure that this is normal behavior, and not a symptom of some other, underlying problem.

And indeed it turns out to be default and well documented behavior of protobuf, see this application note and this discussion.

There's an optional keyword since protoc 3.12 (flag --experimental_allow_proto3_optional) and 3.15 (no longer experimental), to indicate Explicit Presence.

I did a test per these implementation instructions:

• Add this to Generator.hh:

uint64_t GetSupportedFeatures() const override {
return FEATURE_PROTO3_OPTIONAL;
}

• Add optional keyword to float data in float.proto

• Pass --experimental_allow_proto3_optional flag to protoc during build (I put it in a script as I don't know a better way):
  colcon build --merge-install --packages-select gz-msgs9 --cmake-args -DPROTOC_EXEC=/tmp/protoc-exp

This works fine:

gz topic -t /foo -m gz.msgs.Float -p 'data:0.0'

gz topic -e -t /foo
data: 0

So that seems a possible resolution.

Anyway, as there is no real functional impact (other than the 0 values not being echoed), I close this issue.