Fix KeyError for already popped tasks

[mtweiden]

Some more complex instantiation workflows may have several instances of tasks with the same RuntimeAddress. In these cases, multiple calls to remove the task associated with the same RuntimeAddress may call Worker._tasks.pop after it has already been popped.

Adding a default pop value of None avoids raising a KeyError in these scenarios.

Fixes #301

[alonkukl]

I think that the current fix of adding None as a default for the pop is a good fast workaround, but race conditions between the two threads should be treated more carefully.

I will let @edyounis decide if to accept this PR or not.

[edyounis]

@alonkukl What would the benefit of a mutex be for this? The outcome of the race condition shouldn't matter as long as we avoid the error, right?

[alonkukl]

In the current code of the function the only issue I can see is that cancel messages will be sent multiple times to sub tasks, this doesn't seem clean to me. Regarding the _tasks data structure, I agree that it doesn't matter. Alon

…

On Fri, Nov 1, 2024 at 12:17 PM Ed Younis ***@***.***> wrote: ***@***.**** approved this pull request. — Reply to this email directly, view it on GitHub <#300 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQNR6R7QHFXLFDCFQHCPIDZ6PHTRAVCNFSM6AAAAABQ2XMRNGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIMJQG42DAOJXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>