Summary
EntityCapabilities::for_type() resolves supported resource collections per entity TYPE, so every entity detail response advertises URI fields for the full type-level collection set - regardless of what the entity's backing provider actually serves. Plugin-introspected entities are the visible casualty: following an advertised URI returns 404/503.
Observed with the OPC-UA plugin (OpenPLC setup):
- Device Component:
GET /components/<plc>/data -> 404 "No PLC data for entity", /operations -> 404 "Entity not found" - the plugin serves data/operations on the child App, yet the Component advertises both URIs.
- Any plugin Component/App not backed by a ROS node:
/configurations -> 503 "Failed to list parameters from any node" (the gateway falls back to the ROS parameter service for an entity that is not a ROS node).
- Areas advertise
/operations -> 404 "No operation provider for plugin entity".
A client (or the Web UI) walking the tree hits dead endpoints the server itself advertised.
Proposed solution (optional)
Let entities narrow their supported collections:
- Manifest entities: optional
capabilities/collections list per entity.
- Plugin entities: a field on
IntrospectionResult entities so a protocol plugin declares what it registered providers for.
The capability response then includes URI fields only for the declared collections, and validate_collection_access rejects the rest with the proper SOVD error. Default (nothing declared) stays the current per-type set, so existing setups are unaffected.
Additional context (optional)
Found by probing every advertised URI of every entity in a running tree - happy to share the probe script.
Summary
EntityCapabilities::for_type()resolves supported resource collections per entity TYPE, so every entity detail response advertises URI fields for the full type-level collection set - regardless of what the entity's backing provider actually serves. Plugin-introspected entities are the visible casualty: following an advertised URI returns 404/503.Observed with the OPC-UA plugin (OpenPLC setup):
GET /components/<plc>/data-> 404"No PLC data for entity",/operations-> 404"Entity not found"- the plugin serves data/operations on the child App, yet the Component advertises both URIs./configurations-> 503"Failed to list parameters from any node"(the gateway falls back to the ROS parameter service for an entity that is not a ROS node)./operations-> 404"No operation provider for plugin entity".A client (or the Web UI) walking the tree hits dead endpoints the server itself advertised.
Proposed solution (optional)
Let entities narrow their supported collections:
capabilities/collectionslist per entity.IntrospectionResultentities so a protocol plugin declares what it registered providers for.The capability response then includes URI fields only for the declared collections, and
validate_collection_accessrejects the rest with the proper SOVD error. Default (nothing declared) stays the current per-type set, so existing setups are unaffected.Additional context (optional)
Found by probing every advertised URI of every entity in a running tree - happy to share the probe script.