You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These cases don't have much testing, and it's hard to think of cases where it would be valid for them to happen.
They all revolve around the idea of a task completing on multiple workers at once. This is of course possible (anything is possible in a distributed system), but since removing worker reconnect #6361, it shouldn't be possible that a task completes on multiple connected workers at once. That is, before the scheduler would receive the task-finished message, the BatchedStream carrying that message should be disconnected, so the message wouldn't actually be processed.
So far, the only "valid" way we've come up with to trigger these strange transitions is Scheduler.reschedule, which shouldn't be used anyway #7209.
There are a few strange ways the scheduler lets tasks end up in memory:
These cases don't have much testing, and it's hard to think of cases where it would be valid for them to happen.
They all revolve around the idea of a task completing on multiple workers at once. This is of course possible (anything is possible in a distributed system), but since removing worker reconnect #6361, it shouldn't be possible that a task completes on multiple connected workers at once. That is, before the scheduler would receive the
task-finished
message, the BatchedStream carrying that message should be disconnected, so the message wouldn't actually be processed.So far, the only "valid" way we've come up with to trigger these strange transitions is
Scheduler.reschedule
, which shouldn't be used anyway #7209.See discussions for background in:
We should investigate whether these transitions are actually still valid, and if not, remove them.
cc @crusaderky @fjetter
The text was updated successfully, but these errors were encountered: