Summary
GET /{entity}/operations can return two items with the same id, and that id cannot be used.
A ROS 2 service and an action may have the same name and the same path. An action creates its own services under <path>/_action/..., so <path> itself stays free for a plain service. Example: a service /engine/calibrate and an action /engine/calibrate.
The item id has two forms, the short name and the ROS path without the leading slash. For this pair both forms give the same string, so the two operations get the same id. The collection lists both items with that id. A request for it is answered with 400 (refuse_if_ambiguous), so no caller can reach either operation.
The OpenAPI document no longer publishes a path item for such an id, so it does not advertise a request that fails. The collection still reports the duplicate.
Proposed solution (optional)
The addressing scheme needs a way to tell a service from an action at the same path. That changes the id a client uses, so it is a wire contract change and should be decided deliberately, not patched in.
Options to weigh:
- Add a kind marker to the item half for this case only, so ordinary operations keep their current id.
- Keep the ids as they are and have the collection report the pair as one item that says it is ambiguous, with the detail in
x-medkit.
- Leave the runtime as it is and document the limitation.
Option 2 does not change any id and may be enough, since the runtime already refuses the request. Option 1 is the only one that makes both operations reachable.
Additional context (optional)
operation_item_ids() in core/http/operation_item_id.hpp already computes the id for every operation and reports how many operations each id names, so the collection has the information it needs without new plumbing. Unit tests for the three cases are in test/test_operation_item_id.cpp.
Summary
GET /{entity}/operationscan return two items with the sameid, and thatidcannot be used.A ROS 2 service and an action may have the same name and the same path. An action creates its own services under
<path>/_action/..., so<path>itself stays free for a plain service. Example: a service/engine/calibrateand an action/engine/calibrate.The item id has two forms, the short name and the ROS path without the leading slash. For this pair both forms give the same string, so the two operations get the same id. The collection lists both items with that id. A request for it is answered with 400 (
refuse_if_ambiguous), so no caller can reach either operation.The OpenAPI document no longer publishes a path item for such an id, so it does not advertise a request that fails. The collection still reports the duplicate.
Proposed solution (optional)
The addressing scheme needs a way to tell a service from an action at the same path. That changes the id a client uses, so it is a wire contract change and should be decided deliberately, not patched in.
Options to weigh:
x-medkit.Option 2 does not change any id and may be enough, since the runtime already refuses the request. Option 1 is the only one that makes both operations reachable.
Additional context (optional)
operation_item_ids()incore/http/operation_item_id.hppalready computes the id for every operation and reports how many operations each id names, so the collection has the information it needs without new plumbing. Unit tests for the three cases are intest/test_operation_item_id.cpp.