SUBSCRIPTION_INCOMPATIBLE_TYPE and PUBLISHER_INCOMPATIBLE_TYPE are declared supported and never raised

[YuanYuYuan]

RMW_EVENT_SUBSCRIPTION_INCOMPATIBLE_TYPE and RMW_EVENT_PUBLISHER_INCOMPATIBLE_TYPE are reported as supported and are never raised. A subscriber that registers a callback for either gets one that can never fire, and a status that is permanently zero.

Found by an audit of all 11 event types while investigating #292.

The defect shape

For both events, every layer is present except the one that matters:

layer	state
rmw_event_type_is_supported	✅ returns true — rmw_event_type_to_zenoh_event maps 4 and 9 to Some(..)
rmw_event_set_callback	✅ accepts and installs a callback
rmw_take_event	✅ fills the status struct
anything that raises them	❌ nothing

That combination is worse than being unsupported: an application has no way to discover the event will never arrive. Returning false from rmw_event_type_is_supported would at least be honest.

Audit context — this is 2 of 3

rmw event	declared supported	raised	rmw_zenoh_cpp raises
SUBSCRIPTION_MATCHED / PUBLICATION_MATCHED	✅	✅	✅
REQUESTED_QOS_INCOMPATIBLE / OFFERED_QOS_INCOMPATIBLE	✅	✅	❌ — hiroz is ahead
MESSAGE_LOST	✅	❌	✅ — #292
SUBSCRIPTION_INCOMPATIBLE_TYPE / PUBLISHER_INCOMPATIBLE_TYPE	✅	❌	❌ — this issue
LIVELINESS_CHANGED, LIVELINESS_LOST, both DEADLINE_MISSED	❌ (None)	—	— correctly unsupported

The last row is not a defect: those map to None, so rmw_event_type_is_supported returns false and rclcpp never expects them. That is the honest shape this issue asks for — or the events get raised.

Upstream has the same gap, explicitly

rmw_zenoh_cpp does not raise them either, and says so:

// graph_cache.cpp:172
// TODO(Yadunund) Check for and report an *_INCOMPATIBLE_TYPE events.

So this is not a regression against the reference implementation, and it is lower priority than #292 (where hiroz genuinely trails). It is filed because the audit found it and an unwritten gap is an invisible one.

What raising them would need

The event fires when a publisher and subscription on the same topic declare different type hashes. hiroz already carries the material:

• TypeHash is part of EndpointEntity::type_info
• the graph already matches publishers to subscriptions by topic in update_topic_maps_for_put-equivalent paths, which is where SUBSCRIPTION_MATCHED / PUBLICATION_MATCHED are raised

So the natural site is alongside the matched-event raise: when the endpoints match on topic but their type hashes differ, raise the incompatible-type event on the local side instead of (or as well as) the matched one.

Acceptance

• Either both events are raised on a type-hash mismatch, or rmw_event_type_to_zenoh_event maps them to None so rmw_event_type_is_supported stops claiming them
• If raised: via update_shared_event_status, so the callout happens with no lock held (Graph and event callbacks are invoked with up to four locks held (plus an ABBA inversion) #259/fix(event,graph): run event callbacks outside the locks they live under #260)
• A test with two endpoints on one topic and differing type hashes, demonstrated to report zero without the fix