Skip to content
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions rclcpp_action/include/rclcpp_action/client.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -370,14 +370,6 @@ class Client : public ClientBase
// Do not use std::make_shared as friendship cannot be forwarded.
std::shared_ptr<GoalHandle> goal_handle(
new GoalHandle(goal_info, options.feedback_callback, options.result_callback));
{
std::lock_guard<std::mutex> guard(goal_handles_mutex_);
goal_handles_[goal_handle->get_goal_id()] = goal_handle;
}
promise->set_value(goal_handle);
if (options.goal_response_callback) {
options.goal_response_callback(future);
}

if (options.result_callback) {
try {
Expand All @@ -387,6 +379,16 @@ class Client : public ClientBase
return;
}
}

{
std::lock_guard<std::mutex> guard(goal_handles_mutex_);
goal_handles_[goal_handle->get_goal_id()] = goal_handle;
}

promise->set_value(goal_handle);
if (options.goal_response_callback) {
options.goal_response_callback(future);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was moved in response to #701 (review); if make_result_aware is called first, we risk having the result callback triggered before the goal response callback (unlikely, but I think this is possible if the action server is running in the same process).

@hidmic hidmic Sep 10, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, reflecting on this, it seems to me that the goal response callback should simply be taking a concrete goal handle instead of a future one. Additionally, failing to make the goal handle result aware should not result in calling code losing access to the goal handle. Getting the future result should throw, but the exception could carry the goal handle (which is still valid) with it.

That's not a fix we can backport though.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hidmic I agree with everything you've said. I think it's okay to not backport changes (though maybe we could by supporting two different signatures for the goal response callback).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adjusted the goal_response_callback signature, but I'm still not decided about what to do exception and goal handle bit.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove the try-catch altogether. I'll open a PR in a moment with a proposed alternative.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #1311.

}
});

// TODO(jacobperron): Encapsulate into it's own function and
Expand Down