-
Notifications
You must be signed in to change notification settings - Fork 259
Remove duplicate future handling from action client send_goal_async() #1532
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
Conversation
A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. It also preserves the explicit typing annotation on the future. Signed-off-by: Nathan Wiebe Neufeldt <[email protected]>
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.
|
@jmblixt3 can you also take a look? |
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.
Looks good. I think this got introduced since this got rebased so many times.
|
Will need to backported to all versions as well. |
|
@jmblixt3 thank for the review, yeah it took a really long time to put it in, sorry about that. |
|
Pulls: #1532 |
|
all green, i will go head to merge this. |
|
@Mergifyio backport kilted |
✅ Backports have been created
|
A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. It also preserves the explicit typing annotation on the future. Signed-off-by: Nathan Wiebe Neufeldt <[email protected]> (cherry picked from commit 6e22af9)
|
@fujitatomoya Thanks for merging! #1308 needed manual backports to |
|
@nwn yeah right, thanks for fixing this. |
A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. Signed-off-by: Nathan Wiebe Neufeldt <[email protected]> (cherry picked from commit 6e22af9)
A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. Signed-off-by: Nathan Wiebe Neufeldt <[email protected]> (cherry picked from commit 6e22af9)
|
I've created manual backports of this change to Humble and Jazzy since the typing annotations here were not present in those versions. |
A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. (cherry picked from commit 6e22af9) Signed-off-by: Nathan Wiebe Neufeldt <[email protected]>
A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. (cherry picked from commit 6e22af9) Signed-off-by: Nathan Wiebe Neufeldt <[email protected]>
A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. It also preserves the explicit typing annotation on the future. (cherry picked from commit 6e22af9) Signed-off-by: Nathan Wiebe Neufeldt <[email protected]> Co-authored-by: Nathan Wiebe Neufeldt <[email protected]>
Description
A recent change (#1308) intended to move some future-handling logic into a lock context, but actually ended up duplicating it instead. The result is a resource leak in the
Waitable's_futureslist since the future is added twice but only removed once. This fixes that by removing the duplicated logic outside of the lock. It also preserves the explicit typing annotation on the future.Is this user-facing behavior change?
No
Did you use Generative AI?
No
Additional Information