Add option to specify the QoS profile in WaitForTopics
#493
Conversation
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
LastStarDust
force-pushed
the
feature/wait-for-topics-qos
branch
3 times, most recently
from
2a61e63 to
9ca2014
Compare
Signed-off-by: Giorgio Pintaudi <[email protected]> When testing subscribers and publishers, usually we do not want to miss any message due to race issues or other network instabilities. So we give the option to the user to specify a QoS profile best suited for the test scenario. The default is to set the durability to transient local, so that the publisher do not drop any packages in case of late joining subscribers.
LastStarDust
force-pushed
the
feature/wait-for-topics-qos
branch
from
9ca2014 to
4100080
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
During my tests, I noticed that explicitly setting the QoS profile made a big difference in terms of reproducibility and flakiness.
Before, it would happen that integration tests using the
WaitForTopicsclass would randomly fail with timeout errors, probably due to messages not being received by a subscriber. During integration tests where the input and output of a node are cross-checked for consistency, even the loss of a single message can make the test fail which may be unacceptable, for example, in CI workflows that require 100% repeatability.In particular, enforcing QoS policy reliability to “RELIABLE” and QoS policy durability to “TRANSIENT_LOCAL” decreased the chances of tests randomly failing by orders of magnitude.
This is expected, since these options help ensure that all messages are received. Otherwise, in the case of network or other transient issues, a message might get lost, causing the integration test to fail.
Did you use Generative AI?
No
Additional Information
It would be nice if this is backported to Jazzy