GET /{entity}/configurations returns 200 and silently drops a down backing node: in list_configurations (src/ros2_medkit_gateway/src/http/handlers/config_handlers.cpp) per-node failures are only remembered as first_error, and unless every node fails the response is a plain 200 with the unreachable node's parameters missing. There is no partial indicator for local backing nodes (the x-medkit partial flag only covers peer fan-out).
After #540, GET /{entity}/configurations/{param} on the same entity surfaces 503 ERR_X_MEDKIT_ROS2_NODE_UNAVAILABLE when one backing node is down and the others lack the parameter. So the list endpoint reports success in exactly the situation where the single-parameter endpoint reports the node as unavailable - an inconsistent surface between list and get.
Raised in the PR #540 review discussion: #540
GET /{entity}/configurations returns 200 and silently drops a down backing node: in list_configurations (src/ros2_medkit_gateway/src/http/handlers/config_handlers.cpp) per-node failures are only remembered as first_error, and unless every node fails the response is a plain 200 with the unreachable node's parameters missing. There is no partial indicator for local backing nodes (the x-medkit partial flag only covers peer fan-out).
After #540, GET /{entity}/configurations/{param} on the same entity surfaces 503 ERR_X_MEDKIT_ROS2_NODE_UNAVAILABLE when one backing node is down and the others lack the parameter. So the list endpoint reports success in exactly the situation where the single-parameter endpoint reports the node as unavailable - an inconsistent surface between list and get.
Raised in the PR #540 review discussion: #540