Only one example enables the type description service, so runtime-typed tools cannot decode the others

[YuanYuYuan]

ZNodeBuilder::with_type_description_service() is opt-in. One of the 11 examples under crates/hiroz/examples/ calls it: z_custom_message.rs.

Every other example publishes topics that a runtime-typed consumer cannot decode. Nothing answers ~/get_type_description. This affects hu meter echo, dynamic subscribers, and any observability tool.

The documented Quick Start shows the problem, because it pairs z_pubsub with hu:

hu router
cargo run --example z_pubsub -- --role talker
hu meter echo /chatter        # cannot decode: /Pub serves no type description

What the node declares

Run the talker with RUST_LOG=hiroz=debug. Node /Pub declares six queryables. All six belong to ParameterService:

0/Pub/describe_parameters          0/Pub/get_parameters
0/Pub/get_parameter_types          0/Pub/list_parameters
0/Pub/set_parameters               0/Pub/set_parameters_atomically

The list holds no 0/Pub/get_type_description. crates/hiroz/examples/z_pubsub.rs:36 builds the node with ctx.create_node("Pub").build()?. It never calls .with_type_description_service() (crates/hiroz/src/node.rs:139).

ROS 2 defaults this service on, which is the asymmetry that matters. rclcpp declares the parameter with a default of true:

// rclcpp/src/rclcpp/node_interfaces/node_type_descriptions.cpp:73
enable_param = node_parameters->declare_parameter(
    enable_param_name, rclcpp::ParameterValue(true), ...
    .set__description("Start the ~/get_type_description service for this node."));

rclpy declares the same default in rclpy/type_description_service.py. So a standard ROS 2 node serves the request and a hiroz node does not. That also explains why testing against rmw_zenoh_cpp does not reveal the gap.

Relationship to #102

#102 is closed and completed. It made static create_pub<T> register schemas automatically. Its expected behaviour names the precondition:

When a node enables with_type_description_service(), static publishers (create_pub<T>) should expose a queryable schema automatically whenever possible

The machinery works. #102 presupposes the opt-in. This issue reports that the opt-in is never taken, so it is neither a regression nor a re-report.

Options

option	effect	cost
Enable it in the examples that publish	the Quick Start decodes end to end; examples show the intended setup	one line per example
Default it on, add an opt-out	runtime-typed tooling works by default	changes behaviour for existing users; every node gains a queryable and schema registration
Keep it opt-in, document it prominently	no behaviour change	the friction remains; each tool author rediscovers it

The narrow option makes the documented Quick Start work. It does not commit the project to a default.

The docs should state the requirement whichever option wins. A publisher must serve ~/get_type_description for content-decoding consumers to work. Nothing currently says so.

Related

• Schema-discovery failure is swallowed: hu meter echo exits 0 with no output, hu meter delay runs on forever #297 — the same situation produces silence from hu meter echo rather than an error. That is a separate reporting defect. Fix it regardless of this issue.
• create_dyn_sub_auto never falls back to a local .msg, though the publish path does #298 — whether the subscribe path should fall back to a local .msg. That would give a second route to a schema when a publisher serves none.