Skip to content

Make the subscriber_triggered_to_receive_message test more reliable.#2584

Merged
clalancette merged 2 commits intorollingfrom
clalancette/make-sub-trigger-test-reliable
Jul 22, 2024
Merged

Make the subscriber_triggered_to_receive_message test more reliable.#2584
clalancette merged 2 commits intorollingfrom
clalancette/make-sub-trigger-test-reliable

Conversation

@clalancette
Copy link
Copy Markdown
Contributor

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/

@alsora
Copy link
Copy Markdown
Collaborator

alsora commented Jul 13, 2024

Should we force waiting until discovery happens?
For example

while (publisher->get_subscription_count() == 0) {
    std::this_thread::sleep_for(std::chrono::milliseconds(5));
}

Copy link
Copy Markdown
Collaborator

@fujitatomoya fujitatomoya left a comment

Choose a reason for hiding this comment

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

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.

@clalancette
Copy link
Copy Markdown
Contributor Author

Should we force waiting until discovery happens?

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>
@clalancette clalancette force-pushed the clalancette/make-sub-trigger-test-reliable branch from 3245b15 to f2f038c Compare July 22, 2024 12:22
@clalancette
Copy link
Copy Markdown
Contributor Author

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

@clalancette clalancette merged commit 647bd65 into rolling Jul 22, 2024
@clalancette clalancette deleted the clalancette/make-sub-trigger-test-reliable branch July 22, 2024 18:20
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.

3 participants