From 17066cdb342f426eec1fd97187225c4f1bf87101 Mon Sep 17 00:00:00 2001 From: Chris Lalancette Date: Tue, 5 Sep 2023 09:08:39 -0400 Subject: [PATCH] Update the comments for SetParametersResult to reflect reality. (#159) One of the ways that parameter setting can fail is if a user callback (registered with add_on_set_parameters_callback()) rejects it. These callbacks are chained in a Last-In-First-Called manner. Another piece of information to be aware of is that the call to "set_parameters_atomically" has a single SetParametersResult return value. Combining the above two pieces of information, then when "set_parameters_atomically" is called and one of the callbacks rejects it, it can easily set the reason string and return that to the user since no further callbacks are going to be called. However, if a callback accepts it but expects to set a reason code, one of the later callbacks can easily overwrite that return code. Because of this, change the documentation to reflect the reality that a 'reason' can only be specified for the failure case. On success, 'reason' is undefined. Signed-off-by: Chris Lalancette --- rcl_interfaces/msg/SetParametersResult.msg | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rcl_interfaces/msg/SetParametersResult.msg b/rcl_interfaces/msg/SetParametersResult.msg index 4c9e944b..8dd4192b 100644 --- a/rcl_interfaces/msg/SetParametersResult.msg +++ b/rcl_interfaces/msg/SetParametersResult.msg @@ -2,6 +2,6 @@ # successfully. A false value indicates the change was rejected. bool successful -# Reason why the setting was either successful or a failure. This should only be -# used for logging and user interfaces. +# Reason why the setting was a failure. On success, the contents of this field +# are undefined. This should only be used for logging and user interfaces. string reason