[Foxy] Use global namespace for parameter events subscription topic (#1257)#1261
[Foxy] Use global namespace for parameter events subscription topic (#1257)#1261jacobperron merged 1 commit intofoxyfrom
Conversation
Similar to #929, but for the subscription. This fixes an issue listening to parameter events from a remote node when the local node has a different namespace. Originally reported here: https://answers.ros.org/question/358170/parameter-events-on-foxy/ Signed-off-by: Jacob Perron <jacob@openrobotics.org>
|
If we decide to move forward with this backport, we should also backport the same change in rclpy: ros2/rclpy#612 |
wjwwood
left a comment
There was a problem hiding this comment.
For me this is fixing unintended behavior, so a bug fix. Therefore I'm ok with it.
|
rclpy backport: ros2/rclpy#614 |
|
This pull request has been mentioned on ROS Discourse. There might be relevant details there: https://discourse.ros.org/t/global-parameter-events-and-security-ramifications/15924/1 |
|
It sounds like we haven't reached a consensus yet on whether to use global or private topic names for parameter events: But, since I think the current state in Foxy is "broken" because of the asymmetry between the parameter client and parameter sever, I'm going to move forward on this PR. |
|
Backport #1257 to Foxy.
This changes default behavior and could consequently break application code that is relying on the assumption that the parameter events subscription uses a relative namespace (but the publisher is using a global namespace), therefore I'm hesitant about backporting. On the other hand, without the patch it can lead to buggy behavior when trying to use parameter events for the first time in Foxy.
Dashing and Eloquent don't have the same problem since both the publisher and subscription are using relative namespaces.
@ros2/team I'm looking for opinions on whether this fix should be backported or not.