Bugfix: Recorder discovery does not restart after being stopped #1894
Conversation
Repeated calls to start_discovery should not start additional topics discovery tasks without stop_discovery calls Signed-off-by: Øystein Sture <[email protected]>
|
The can_record_again_after_stop is failing because it records one more message than expected. If discovery now works between the record calls, it makes sense that it records something else as well, e.g., rosout? |
There was a problem hiding this comment.
@oysstu thank you for PR and attempt to fix a wrong behavior.
The naming is hard! It seems the root cause of the issue is in unclear naming fo the variable stop_discovery_.
The logic would be more readable and much easy to understand if stop_discovery_ would be renamed to the discovery_runing_.
Could you please do such rename in the code and change conditions accordingly?
MichaelOrlov
changed the title
Signed-off-by: Øystein Sture <[email protected]>
|
I've made the change, that should clarify the logic a lot. Edit: seemed to pass tests this time |
|
Pulls: #1894
|
Repeated calls to start_discovery should not start additional topics discovery tasks without stop_discovery calls.
This was originally reported in #1893, as discovery task would not be spawned if a previous stop_discovery call was made. This only works currently because the atomic is initialized to false, thus making the "correct" choice on the first call after construction.