Make the subscriber_triggered_to_receive_message test more reliable.#2584
Merged
clalancette merged 2 commits intorollingfrom Jul 22, 2024
Merged
Make the subscriber_triggered_to_receive_message test more reliable.#2584clalancette merged 2 commits intorollingfrom
clalancette merged 2 commits intorollingfrom
Conversation
Collaborator
|
Should we force waiting until discovery happens? |
fujitatomoya
approved these changes
Jul 19, 2024
Collaborator
fujitatomoya
left a comment
There was a problem hiding this comment.
i think test purpose here is to use the same callback group to the subscription to make sure the executor is triggered when creating the subscription. that said, we do not need to create the subscription or publisher in the timer callback for the test. this change looks good to me.
giving 100 msec for the discovery would be enough, but rcl_wait_for_subscribers could be used for checking the discovery completion before creating timer as @alsora suggested.
Contributor
Author
Yeah, that's fair. I'm actually going to change the timer callback to check for discovery to happen. |
In the current code, inside of the timer we create the subscription and the publisher, publish immediately, and expect the subscription to get it immediately. But it may be the case that discovery hasn't even happened between the publisher and the subscription by the time the publish call happens. To make this more reliable, create the subscription and publish *before* we ever create and spin on the timer. This at least gives 100 milliseconds for discovery to happen. That may not be quite enough to make this reliable on all platforms, but in my local testing this helps a lot. Prior to this change I can make this fail one out of 10 times, and after the change I've run 100 times with no failures. Signed-off-by: Chris Lalancette <clalancette@gmail.com>
Signed-off-by: Chris Lalancette <clalancette@gmail.com>
3245b15 to
f2f038c
Compare
Contributor
Author
alsora
approved these changes
Jul 22, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In the current code, inside of the timer we create the subscription and the publisher, publish immediately, and expect the subscription to get it immediately. But it may be the case that discovery hasn't even happened between the publisher and the subscription by the time the publish call happens.
To make this more reliable, create the subscription and publish before we ever create and spin on the timer. This at least gives 100 milliseconds for discovery to happen. That may not be quite enough to make this reliable on all platforms, but in my local testing this helps a lot. Prior to this change I can make this fail one out of 10 times, and after the change I've run 100 times with no failures.
FYI @iuhilnehc-ynos .
@wjwwood If you have time to look at this, I'd appreciate a review.
@Crola1702 FYI, this should fix the flaky test https://ci.ros2.org/view/nightly/job/nightly_linux_repeated/3515/testReport/junit/rclcpp/TestAddCallbackGroupsToExecutorStable_MultiThreadedExecutor/subscriber_triggered_to_receive_message/