Skip to content
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

Added tool to request transition to ErrorState #1758

Closed
wants to merge 2 commits into from

Conversation

gimait
Copy link
Contributor

@gimait gimait commented May 21, 2020

Signed-off-by: Aitor Miguel Blanco aitormibl@gmail.com

Included tool in lifecycle utils to call a transition to the error state in lifecycle nodes.


Basic Info

Info Please fill out this column
Ticket(s) this addresses -
Primary OS tested on Ubuntu 20.04
Robotic platform tested on -

Description of contribution in a few bullet points

This is a preliminary version of the tool, and I would like to ask for some feedback.

At the moment, this tool can only transition from Transition States to ErrorProcessing. This is because the Primary States do not include (yet) the transitions to the ErrorProcessing state.

The pull requests ros2/rcl_interfaces#97, ros2/rcl#618 and ros2/rclcpp#1064 address this issue by including the extra transitions for Primary States plus a raise_error function that triggers the transition from the active and inactive states.

Because of this limitation, it won't be that easy to test the on_error callback from lifecycle nodes until the mentioned PRs are merged.

I would also appreciate any ideas about how to test the tool itself. I can only think on creating a mock class that waits on specific states for the error to be triggered.

Description of documentation updates required from your changes


Future work that may be required in bullet points

Signed-off-by: Aitor Miguel Blanco <aitormibl@gmail.com>
Copy link
Member

@SteveMacenski SteveMacenski left a comment

Choose a reason for hiding this comment

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

Looks good, really small changes. Can you also include a test that covers this? I know we'll also write a test using this for all the on_error methods, but we should make sure this itself works. You can do this by making a small lifecycle node that you transition to the valid states (configure, cleanup, shut down, activate, deactivate) and then calling this and verifying that its now in the error state with a boolean.

@@ -77,6 +77,33 @@ void reset_lifecycle_nodes(
reset_lifecycle_nodes(split(nodes, ':'), service_call_timeout, retries);
}

/// Transition the given lifecycle nodes to the ErrorProcessing state in order
/** At this time, service calls frequently hang for unknown reasons. The only
* way to combat that is to timeout the service call and retry it. To use this
Copy link
Member

Choose a reason for hiding this comment

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

I'm really curious, is this timeout issue still an issue? That was circa Bouncy when that message was added to this tool, we've come a long way since then.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I actually have no idea, I added it as well for consistency with the other tools. I can take a look at it and see if this was fixed somewhere. Or if you know how to test it?

Copy link
Member

Choose a reason for hiding this comment

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

Eh, lets just leave it. Its not hurting anyone. But I would be curious if in your unit tests you set the number of retries to 0 so that it fails and see if we ever catch it in your development / CI later. If it doesn't cause problems, we can remove it later.

// to the ErrorProcessing state. Some states do not support transitions
// to ErrorProcessing.
switch (sc.get_state(service_call_timeout)) {
case State::PRIMARY_STATE_UNKNOWN:
Copy link
Member

Choose a reason for hiding this comment

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

For all of these return cases, please throw an exception since they're invalid.

@gimait
Copy link
Contributor Author

gimait commented May 21, 2020

Can you also include a test that covers this? I know we'll also write a test using this for all the on_error methods, but we should make sure this itself works.

Yes I would like to write a test for the tool as well, but I wanted to ask for help on how to make it.

You can do this by making a small lifecycle node that you transition to the valid states (configure, cleanup, shut down, activate, deactivate) and then calling this and verifying that its now in the error state with a boolean.

I'll try something like that then, it's similar to what I though. Thanks!

@SteveMacenski
Copy link
Member

For the exception, you can also just have the valid cases as cases, and then the default is throwing the exception so you don't need to list all of them.

Then in the test, also make sure you trigger that exception case for one of those states, doesn't matter which .

Signed-off-by: Aitor Miguel Blanco <aitormibl@gmail.com>
@gimait
Copy link
Contributor Author

gimait commented Jun 9, 2020

Since the lifecycle node transitions to the ErrorProcessing state are not exposed to client nodes (they are only internal transitions), it won't be possible to test the on_error state with this tool.

Since the tool is very much useless, I'll close this pull request. It could be reopened though if the lifecycle transitions are updated to ErrorProcessing are updated.

@gimait gimait closed this Jun 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants