-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add payloads to Action #66
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like the idea of a payload, my original thought was to make it a file path to json files and this easily extends to that and more. I would like to include some tooling to make working with json encoded strings and files easy because I see that as a common use case! But that can come in future PRs.
As far as the tree failing and the result of the action returning aborted, I think it makes sense. Let's say I make a behavior that asks the user if the tree should continue and they say no, or we need sensor data and it's not available. If the tree finishes early and is not able to finish wouldn't that be considered aborting?
10d4cef
to
06402c0
Compare
@MarqRazz check my latest changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work simplifying 🥇
NodeStatus node_status | ||
# result payload or error message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we override the return message or add a payload for this additional information in the result? What if the tree errors/fails and there is useful information in the result_message but we also want a payload? It looks like the message is not overwritten when we encounter an exception and that is the only place I can think of where we need the additional info so maybe 1 string is enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we already have many hints about the fact that an error occurred:
- the Action client returned a gola aborted or cancelled
- NodeStatus will not be SUCCESS
Also, the payload may contain both human-readable and machine-readable data (not my problem 😝 )
{ | ||
return p_->tree ? p_->tree.get() : nullptr; | ||
return p_->tree; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any chance of the user accessing the tree and it being outdated or empty? It doesn't seem like there is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically an empty Tree can be recognized.
But in general I don't believe this can happen, this is the reason why I made the change
The main goal of this PR is to support users that want to send and receive more comple payloads, when executing a Tree (arguments and return values).
A single string is used for both, since the majority of the users can use JSON to store any argitrary set of arguments.
The return value of
onTreeExecutionCompleted
has been changed to support a return value.Also, about this code :
I don't think that a FAILURe shoult trigger a
goal_handle->abort
since, from a technical point of view, the tree has been executed.