-
Notifications
You must be signed in to change notification settings - Fork 488
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
Improve transport::Publisher reliability #2725
Improve transport::Publisher reliability #2725
Conversation
Thanks for the PR, @nlamprian . Do you think it would be possible to write a test that exercises the fix? |
Oof, this will require some effort. I'll need to familiarize myself with the full implementation to understand how to trigger the conditions. I'll give it a try. |
The unit test is added. It successfully reproduces the error. Basically, for the error to show up, there have to be callbacks in the |
2a2c94f
to
1a96bbc
Compare
May I please ask for an update on this? Is there something holding back the review? The publisher continues to be a problem for me, and I would hope to see it fixed soon. |
@osrf-jenkins run tests Thank you for the contribution and the test, it looks good to me. Let's just run a round of CI to make sure everything is ok. |
@osrf-jenkins run tests again? |
1a96bbc
to
99b8d87
Compare
@osrf-jenkins run 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.
The fix and test look good and CI is happy 👍
It has been observed that
OnPublishComplete
can run beforeresult
is checked inSendMessage
. In that case, thepubIds
entry is deleted byOnPublishComplete
, and then it's recreated inSendMessage
. This blocks publication of any future messages, thus rendering the publisher unusable.The fix guards access to
pubIds
inSendMessage
, and it processes thepubIds
entry only if it still exists.