Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fixes for flaky WPF test #3785
Fixes for flaky WPF test #3785
Changes from all commits
139142f
8647da5
2912c92
85b6b71
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 this really a failed case if unknown from this timeout? Seems like we should instead temporarily increase the timeout back to 15 minutes (@pepisg ) while working through a potential patch to rclcpp to better keep actively processing goals around.
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.
Exposed that as a parameter in #3787 that defaults to 15 min
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.
@AlexeyMerzlyakov do you think we should remove this bit and instead use #3787 as the temp work around?
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.
This PR is complementary with PR3787, that improves the situation and fixes some bugs, that 3787 does not. So both PR-s ought to be merged (moreover, new parameters in RewrittenYaml I plan to use to comb-up Costmap Filters system tests).
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.
@AlexeyMerzlyakov I meant only the addition of
|| current_goal_status_.status == ActionStatus::UNKNOWN
. I thought this line was to mask the unknown return type problem? If we increase the timeout, wouldn't that make it so we didn't seeUNKNOWN
? This logic treatsUNKNOWN
as a terminal condition failure, which I suppose is an interpretation. I could get behind that but:If we keep this here should https://github.com/ros-planning/navigation2/pull/3785/files#diff-872945d6a63001626ab7379639b5b3d5f11982ea3bdf08da01e7f111a9c2dfecR279 be changed for incrementing new goals? You're treating UNKNOWN as a terminal condition in your change, so this doesn't make as much sense anymore as a potentially non-terminal condition, correct? Is there anywhere UNKNOWN is potentially set where its not terminal?
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.
This status is being treated as terminal one for WPF server in order to avoid infinite cycles whether for some reasons the goal got into "UNKNOWN" state. This is intended to fix/mask not only the case when the goal is getting after it was destroyed, but rather for any other potential problems. Briefly looking to RCLCPP and RCL code shows that UNKNOWN state might appear in case if goal was invalidated, destroyed, does not exists at the moment of if the transition was invalid or any other error occurred. So, receiving UNKNOWN goal for action server seems to be treated as problem state, if I got the RCLCPP / RCL intention correctly.
When I've wrote this change, I've also focused on
BtActionNode
server, receiving the result from downstream nodes. For this case, "UNKNOWN" status is being treated as error situation, and error is being thrown, interrupting normal operation.From this point of view, looking on the UNKNOWN goal status as on error seems to be logical.
Yes, this should be removed for UNKNOWN stage, if we will treat UNKNOWNS as errors. Thanks for the notice!
If we will agree on main idea, I will remove it in next update.
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.
Yup that works for me!
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.
Fixed in 85b6b71